[Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I still see failures on ppc64: trippels@gcc1-power7 testsuite % ~/gcc_test/usr/local/bin/gcc -c -O2 -Wno-psabi gcc.dg/pr63594-1.c gcc.dg/pr63594-1.c: In function ‘test1char64’: gcc.dg/pr63594-1.c:35:1: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee T(char, 64) ^ trippels@gcc1-power7 testsuite % ~/gcc_test/usr/local/bin/gcc -c -O2 -Wno-psabi gcc.dg/pr63594-2.c gcc.dg/pr63594-2.c: In function ‘test1char64’: gcc.dg/pr63594-2.c:83:1: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee TESTS ^
[Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63594 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #10) I still see failures on ppc64: trippels@gcc1-power7 testsuite % ~/gcc_test/usr/local/bin/gcc -c -O2 -Wno-psabi gcc.dg/pr63594-1.c gcc.dg/pr63594-1.c: In function ‘test1char64’: gcc.dg/pr63594-1.c:35:1: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee T(char, 64) ^ trippels@gcc1-power7 testsuite % ~/gcc_test/usr/local/bin/gcc -c -O2 -Wno-psabi gcc.dg/pr63594-2.c gcc.dg/pr63594-2.c: In function ‘test1char64’: gcc.dg/pr63594-2.c:83:1: warning: GCC vector returned by reference: non-standard ABI extension with no compatibility guarantee TESTS ^ That sounds like a rs6000 backend issue, IMNSHO those warnings should be guarded by OPT_Wpsabi, like they are in other backends.
[Bug bootstrap/63632] [4.9/5 Regression] bootstrap-lto/profiledbootstrap broken by r216566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63632 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed.
[Bug c/55965] gcc -std=c99 emits code for inline even without extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55965 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- The implicit builtin FUNCTION_DECL should have UNKNOWN_LOCATION or BUILTIN_LOCATION, so should be easy to differentiate from explicit user extern decl. Just it is important that when an inline without extern is merged with the implicit decl that the result doesn't look like user extern inline or user extern decl followed by inline decl.
[Bug target/63636] New: [5 Regression] gcc gets miscompiled during LTO/PGO bootstrap on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63636
Bug ID: 63636
Summary: [5 Regression] gcc gets miscompiled during LTO/PGO
bootstrap on ppc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target: powerpc64-unknown-linux-gnu
% ../gcc/configure --disable-libsanitizer -disable-libstdcxx-pch
--disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp
--disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++
--with-build-config=bootstrap-lto
% make -j64 BOOT_CFLAGS=-mcpu=power7 -O3 -pipe STAGE1_CFLAGS=-mcpu=power7
-O3 -pipe CFLAGS_FOR_TARGET=-mcpu=power7 -O3 -pipe
CXXFLAGS_FOR_TARGET=-mcpu=power7 -O3 -pipe profiledbootstrap
... (stagefeedback)
../../../gcc/libgcc/libgcov-merge.c: In function ‘__gcov_merge_ior’:
../../../gcc/libgcc/libgcov-merge.c:69:1: error: unrecognizable insn:
}
^
(insn 53 52 54 6 (set (reg:DI 196 [ D.8309 ])
(ior:DI (reg:DI 197)
(reg:DI 182 [ D.8310 ]))) ../../../gcc/libgcc/libgcov-merge.c:68 -1
(nil))
../../../gcc/libgcc/libgcov-merge.c:69:1: internal compiler error: in
extract_insn, at recog.c:2321
(And many similar ICEs)
trippels@gcc1-power7 libgcc % cat unwind-dw2.i
int a;
void
_Unwind_RaiseException_handler (void)
{
__builtin_eh_return (a, _Unwind_RaiseException_handler);
}
trippels@gcc1-power7 libgcc % /home/trippels/gcc_build_dir/./gcc/xgcc
-B/home/trippels/gcc_build_dir/./gcc/ unwind-dw2.i
unwind-dw2.i: In function ‘_Unwind_RaiseException_handler’:
unwind-dw2.i:6:1: error: unrecognizable insn:
}
^
(insn 31 30 32 (set (reg:SI 11 11)
(xor:SI (reg:SI 11 11)
(const_int -398393344 [0xe841]))) unwind-dw2.i:4 -1
(nil))
unwind-dw2.i:6:1: internal compiler error: in insn_default_length, at
config/rs6000/rs6000.md:7570
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/63632] [4.9/5 Regression] bootstrap-lto/profiledbootstrap broken by r216566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63632 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) Fixed. Thanks! Commits were r216613 (trunk) and r216614 (4.9).
[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #12 from Yuri Rumyantsev ysrumyan at gmail dot com --- Richard, Did you have a chance to look at this and prepare more general fix? Thanks. Yuri. 2014-09-08 15:13 GMT+04:00 rguenther at suse dot de gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #11 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 8 Sep 2014, ysrumyan at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #10 from Yuri Rumyantsev ysrumyan at gmail dot com --- Richard, Do you have any progress? No, I didn't yet have time to get back to this. -- You are receiving this mail because: You reported the bug.
[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 24 Oct 2014, ysrumyan at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #12 from Yuri Rumyantsev ysrumyan at gmail dot com --- Richard, Did you have a chance to look at this and prepare more general fix? No, I'm swamped with other work. I plan to look into this during stage3.
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #8 from Martin Liška marxin at gcc dot gnu.org ---
I added assert to cgraphunit.c (expand_thunk):1547:
/* Build call to the function being thunked. */
if (!VOID_TYPE_P (restype))
{
if (DECL_BY_REFERENCE (resdecl))
restmp = gimple_fold_indirect_ref (resdecl);
else if (!is_gimple_reg_type (restype))
{
restmp = resdecl;
gcc_assert (TREE_CODE (restmp) == VAR_DECL);
add_local_decl (cfun, restmp);
BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
}
else
restmp = create_tmp_reg (restype, retval);
}
It's triggered quite often, one example of a thunk created by IPA ICF:
Well, the bug is the add_local_decl being called with a RESULT_DECL.
Thus you should try placing an assert into add_local_decl instead
(need to move it out-of-line for that).
std::basic_streambuf_CharT, _Traits::pos_type std::basic_streambuf_CharT,
_Traits::seekpos(std::basic_streambuf_CharT, _Traits::pos_type,
std::ios_base::openmode) [with _CharT = char; _Traits =
std::char_traitschar;
std::basic_streambuf_CharT, _Traits::pos_type = std::fpos__mbstate_t;
std::ios_base::openmode = std::_Ios_Openmode] (struct basic_streambuf * const
this, struct pos_type D.23077, openmode D.23078)
{
struct pos_type retval;
bb 2:
retval = std::basic_streambufwchar_t::seekpos (this_2(D), D.23077,
_3(D)); [tail call]
return retval;
}
where std::basic_streambuf_CharT, _Traits::pos_type is:
result_decl 0x74eec708 D.39821
type record_type 0x759c2150 pos_type sizes-gimplified asm_written
used
needs-constructing type_1 type_5 TI
size integer_cst 0x76c2fe40 constant 128
unit size integer_cst 0x76c2fe58 constant 16
align 64 symtab -164402368 alias set -1 canonical type 0x7614adc8
fields field_decl 0x751cd850 _M_off type integer_type
0x7678c738 streamoff
used private nonlocal decl_3 DI file
/home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/postypes.h
line 115 col 33
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 offset_align 128
offset integer_cst 0x76c2fe28 constant 0
bit offset integer_cst 0x76c2fe70 constant 0 context
record_type 0x7614adc8 fpos chain field_decl 0x751cd8e8 _M_state
context namespace_decl 0x76c4c098 std
full-name std::basic_streambufchar::pos_type
needs-constructor X() has-type-conversion X(constX) this=(X)
n_parents=0 use_template=1 interface-unknown
pointer_to_this pointer_type 0x75224e70 chain type_decl
0x76146da8 fpos
ignored TI file
/home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/streambuf
line 602 col 7 size integer_cst 0x76c2fe40 128 unit size integer_cst
0x76c2fe58 16
align 64 context function_decl 0x75797948 seekoff
Is there a bug in expand_thunk or do I miss something?
Thanks,
Martin
[Bug target/63636] [5 Regression] gcc gets miscompiled during LTO/PGO bootstrap on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63636 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jwakely.gcc at gmail dot com, ||paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- This weird issue has to do with atomic including stdbool.h via atomic_base.h. I don't know why it does that. (minor, unrelated, nit I also noticed: when atomic sees __cplusplus 201103L it should *only* include c++0x_warning.h). Jon, any idea about stdbool.h? Out of curiousity, want to see if something breaks if I simply comment it out...
[Bug middle-end/61529] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:953
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529 --- Comment #8 from Renlin Li renlin.li at arm dot com --- I believe we observed the same behavior, and the first commit to cause the ICE is r215739. The newly introduced recompute_probabilities will set the probability back to REG_BR_PROB_BASE. I will further dig into it.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Well, of course the user can always explicitly include, eg, cstdbool, thus it seems that the real underlying issue is that the system-headers machinery should not be fooled by things like this in a system header... or should it? The define is rather interesting... #define false false I'm adding in CC Dodji too...
[Bug target/61535] [5 Regression] SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- This also affects the new gcc.dg/pr63594-1.c and gcc.dg/pr63594-2.c testcases. Rainer
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #5) #define false false No idea what's going on, but I think I have a patch somewhere to disable that macro for C++, it's very explicitly non-conforming: [support.runtime]/8 The header cstdbool and the header stdbool.h shall not define macros named bool, true, or false. Let me dig out the old patch. I also remember some discussion with Joseph IIRC.
[Bug c++/63582] [5 Regression]: g++.dg/init/enum1.C ... (test for errors, line 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added CC||jiwang at gcc dot gnu.org --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- also on arm-none-linux-gnueabi, arm-none-linux-gnueabihf, arm-none-eabi
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Ah, that makes a lot of sense! If testing goes well, I mean to commit the below, which in any case shouldn't hurt: Index: include/bits/atomic_base.h === --- include/bits/atomic_base.h (revision 216624) +++ include/bits/atomic_base.h (working copy) @@ -33,7 +33,6 @@ #pragma GCC system_header #include bits/c++config.h -#include stdbool.h #include stdint.h #include bits/atomic_lockfree_defines.h Index: include/std/atomic === --- include/std/atomic (revision 216624) +++ include/std/atomic (working copy) @@ -36,7 +36,7 @@ #if __cplusplus 201103L # include bits/c++0x_warning.h -#endif +#else #include bits/atomic_base.h @@ -1129,4 +1129,6 @@ _GLIBCXX_END_NAMESPACE_VERSION } // namespace -#endif +#endif // C++11 + +#endif // _GLIBCXX_ATOMIC
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- See https://gcc.gnu.org/ml/gcc-patches/2012-01/msg00375.html Gerald objected to the patch saying the dumb macros should be defined for C++98 mode or it will break code. Not sure I agree, but I'll adjust the patch to only define them when __cplusplus 201103L
[Bug target/61535] [5 Regression] SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-24 Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- RTL checking tells a little more: eric@polaris:~/build/gcc/sparc-sun-solaris2.10 gcc/cc1 -quiet vect-singleton_1.i -m64 /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c: In function 'test_vadd_f32': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c:30:91: internal compiler error: RTL check: access of elt 0 of vector with last elt -1 in gen_group_rtx, at expr.c:1622 0xcae23f rtvec_check_failed_bounds(rtvec_def const*, int, char const*, int, char const*) /home/eric/svn/gcc/gcc/rtl.c:787 0x8f9258 gen_group_rtx(rtx_def*) /home/eric/svn/gcc/gcc/expr.c:1622 0x9b8e3f expand_function_start(tree_node*) /home/eric/svn/gcc/gcc/function.c:4803 0x7a8148 execute /home/eric/svn/gcc/gcc/cfgexpand.c:5709 Please submit a full bug report, with preprocessed source if appropriate.
[Bug target/61535] [5 Regression] SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Investigating.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573
--- Comment #2 from Martin Liška marxin at gcc dot gnu.org ---
More precise back-trace:
../../../../libgo/go/path/filepath/path.go:158:1: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:7665
func ToSlash(path string) string {
^
0x10501373 expand_expr_addr_expr_1
../../gcc/expr.c:7665
0x10501d93 expand_expr_addr_expr
../../gcc/expr.c:7779
0x10510797 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10604
0x105023af expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:7947
0x1032b413 expand_normal
../../gcc/expr.h:457
0x1032d4bf precompute_register_parameters
../../gcc/calls.c:832
0x10335813 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:3009
0x1050f433 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10372
0x105023af expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:7947
0x104f5e1f store_expr(tree_node*, rtx_def*, int, bool)
../../gcc/expr.c:5337
0x104f47e3 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5123
0x103505a3 expand_call_stmt
../../gcc/cfgexpand.c:2321
0x103545c7 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3218
0x10354df3 expand_gimple_stmt
../../gcc/cfgexpand.c:3370
0x10354f73 expand_gimple_tailcall
../../gcc/cfgexpand.c:3417
0x1035d3d7 expand_gimple_basic_block
../../gcc/cfgexpand.c:5182
0x1035f983 execute
../../gcc/cfgexpand.c:5811
Where debug_rtx(result):
(reg/v:DI 157 [ path ])
if I go up in BT:
#11 0x103505a4 in expand_call_stmt (stmt=0x3fffafcc5bb0) at
../../gcc/cfgexpand.c:2321
2321expand_assignment (lhs, exp, false);
(gdb) call debug_gimple_stmt(stmt)
# .MEM_2 = VDEF .MEM_1(D)
retval = path_filepath.FromSlash.localalias.1 (path); [return slot
optimization] [tail call]
I think it would be duplicate of PR63587, where we expand thunk and RESULT_DECL
is given as argument for add_local_decl.
Thanks,
Martin
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška marxin at gcc dot gnu.org --- Duplicate. *** This bug has been marked as a duplicate of bug 63587 ***
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #11 from Martin Liška marxin at gcc dot gnu.org --- *** Bug 63573 has been marked as a duplicate of this bug. ***
[Bug ipa/63636] [5 Regression] gcc gets miscompiled during LTO/PGO bootstrap on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63636 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-24 Component|target |ipa Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Another ipa-icf issue. Adding -fno-ipa-icf to STAGE2/3_CFLAGS fixes the issue. I will wait until all the other ICF issues are fixed and retest then.
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #12 from Martin Liška mliska at suse dot cz ---
On 10/24/2014 10:44 AM, rguenther at suse dot de wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #8 from Martin Liška marxin at gcc dot gnu.org ---
I added assert to cgraphunit.c (expand_thunk):1547:
/* Build call to the function being thunked. */
if (!VOID_TYPE_P (restype))
{
if (DECL_BY_REFERENCE (resdecl))
restmp = gimple_fold_indirect_ref (resdecl);
else if (!is_gimple_reg_type (restype))
{
restmp = resdecl;
gcc_assert (TREE_CODE (restmp) == VAR_DECL);
add_local_decl (cfun, restmp);
BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
}
else
restmp = create_tmp_reg (restype, retval);
}
It's triggered quite often, one example of a thunk created by IPA ICF:
Well, the bug is the add_local_decl being called with a RESULT_DECL.
Thus you should try placing an assert into add_local_decl instead
(need to move it out-of-line for that).
You are right, it would be good to place assert to add_local_decl function,
attachment contains suggested patch
that I will regtest.
Problematic is that one would like to place assert to function.h, but gengtype
does not include tree.h
for gencondmd.c:
In file included from build/gencondmd.c:5:0:
../../gcc/function.h: In function ‘void add_local_decl(function*, tree)’:
../../gcc/function.h:674:27: error: ‘TREE_CODE’ was not declared in this scope
gcc_assert (TREE_CODE (d) == VAR_DECL);
Is it acceptable to put the implementation to function.c?
Thanks,
Martin
std::basic_streambuf_CharT, _Traits::pos_type std::basic_streambuf_CharT,
_Traits::seekpos(std::basic_streambuf_CharT, _Traits::pos_type,
std::ios_base::openmode) [with _CharT = char; _Traits =
std::char_traitschar;
std::basic_streambuf_CharT, _Traits::pos_type = std::fpos__mbstate_t;
std::ios_base::openmode = std::_Ios_Openmode] (struct basic_streambuf * const
this, struct pos_type D.23077, openmode D.23078)
{
struct pos_type retval;
bb 2:
retval = std::basic_streambufwchar_t::seekpos (this_2(D), D.23077,
_3(D)); [tail call]
return retval;
}
where std::basic_streambuf_CharT, _Traits::pos_type is:
result_decl 0x74eec708 D.39821
type record_type 0x759c2150 pos_type sizes-gimplified asm_written
used
needs-constructing type_1 type_5 TI
size integer_cst 0x76c2fe40 constant 128
unit size integer_cst 0x76c2fe58 constant 16
align 64 symtab -164402368 alias set -1 canonical type
0x7614adc8
fields field_decl 0x751cd850 _M_off type integer_type
0x7678c738 streamoff
used private nonlocal decl_3 DI file
/home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/postypes.h
line 115 col 33
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 offset_align 128
offset integer_cst 0x76c2fe28 constant 0
bit offset integer_cst 0x76c2fe70 constant 0 context
record_type 0x7614adc8 fpos chain field_decl 0x751cd8e8 _M_state
context namespace_decl 0x76c4c098 std
full-name std::basic_streambufchar::pos_type
needs-constructor X() has-type-conversion X(constX) this=(X)
n_parents=0 use_template=1 interface-unknown
pointer_to_this pointer_type 0x75224e70 chain type_decl
0x76146da8 fpos
ignored TI file
/home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/streambuf
line 602 col 7 size integer_cst 0x76c2fe40 128 unit size integer_cst
0x76c2fe58 16
align 64 context function_decl 0x75797948 seekoff
Is there a bug in expand_thunk or do I miss something?
Thanks,
Martin
[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #13 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 24 Oct 2014, mliska at suse dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #12 from Martin Liška mliska at suse dot cz ---
On 10/24/2014 10:44 AM, rguenther at suse dot de wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587
--- Comment #8 from Martin Liška marxin at gcc dot gnu.org ---
I added assert to cgraphunit.c (expand_thunk):1547:
/* Build call to the function being thunked. */
if (!VOID_TYPE_P (restype))
{
if (DECL_BY_REFERENCE (resdecl))
restmp = gimple_fold_indirect_ref (resdecl);
else if (!is_gimple_reg_type (restype))
{
restmp = resdecl;
gcc_assert (TREE_CODE (restmp) == VAR_DECL);
add_local_decl (cfun, restmp);
BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
}
else
restmp = create_tmp_reg (restype, retval);
}
It's triggered quite often, one example of a thunk created by IPA ICF:
Well, the bug is the add_local_decl being called with a RESULT_DECL.
Thus you should try placing an assert into add_local_decl instead
(need to move it out-of-line for that).
You are right, it would be good to place assert to add_local_decl function,
attachment contains suggested patch
that I will regtest.
Problematic is that one would like to place assert to function.h, but gengtype
does not include tree.h
for gencondmd.c:
In file included from build/gencondmd.c:5:0:
../../gcc/function.h: In function ‘void add_local_decl(function*, tree)’:
../../gcc/function.h:674:27: error: ‘TREE_CODE’ was not declared in this scope
gcc_assert (TREE_CODE (d) == VAR_DECL);
Is it acceptable to put the implementation to function.c?
Yes.
Richard.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #5) Well, of course the user can always explicitly include, eg, cstdbool, thus it seems that the real underlying issue is that the system-headers machinery should not be fooled by things like this in a system header... or should it? The define is rather interesting... #define false false I'm adding in CC Dodji too... In the case of NULL we do: source_location loc = expansion_point_location_if_in_system_header (input_location); however, we do not do it in the case of 'false' (because we do not think it should be a macro, but it actually is). Perhaps we should do it, is there a downside to it?
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #9) (In reply to Paolo Carlini from comment #5) Well, of course the user can always explicitly include, eg, cstdbool, thus it seems that the real underlying issue is that the system-headers machinery should not be fooled by things like this in a system header... or should it? The define is rather interesting... #define false false I'm adding in CC Dodji too... In the case of NULL we do: source_location loc = expansion_point_location_if_in_system_header (input_location); however, we do not do it in the case of 'false' (because we do not think it should be a macro, but it actually is). Perhaps we should do it, is there a downside to it? BTW, this is the guideline I was asking for here: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01783.html In this case, 'false' is one of those special macros.
[Bug target/63173] performance problem with simd intrinsics vld2_dup_* on aarch64-none-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63173 --- Comment #8 from fyang at gcc dot gnu.org --- Author: fyang Date: Fri Oct 24 10:53:08 2014 New Revision: 216630 URL: https://gcc.gnu.org/viewcvs?rev=216630root=gccview=rev Log: PR target/63173 * config/aarch64/arm_neon.h (__LD2R_FUNC): Remove macro. (__LD3R_FUNC): Ditto. (__LD4R_FUNC): Ditto. (vld2_dup_s8, vld2_dup_s16, vld2_dup_s32, vld2_dup_f32, vld2_dup_f64, vld2_dup_u8, vld2_dup_u16, vld2_dup_u32, vld2_dup_p8, vld2_dup_p16 vld2_dup_s64, vld2_dup_u64, vld2q_dup_s8, vld2q_dup_p8, vld2q_dup_s16, vld2q_dup_p16, vld2q_dup_s32, vld2q_dup_s64, vld2q_dup_u8, vld2q_dup_u16, vld2q_dup_u32, vld2q_dup_u64 vld2q_dup_f32, vld2q_dup_f64): Rewrite using builtin functions. (vld3_dup_s64, vld3_dup_u64, vld3_dup_f64, vld3_dup_s8 vld3_dup_p8, vld3_dup_s16, vld3_dup_p16, vld3_dup_s32 vld3_dup_u8, vld3_dup_u16, vld3_dup_u32, vld3_dup_f32 vld3q_dup_s8, vld3q_dup_p8, vld3q_dup_s16, vld3q_dup_p16 vld3q_dup_s32, vld3q_dup_s64, vld3q_dup_u8, vld3q_dup_u16 vld3q_dup_u32, vld3q_dup_u64, vld3q_dup_f32, vld3q_dup_f64): Likewise. (vld4_dup_s64, vld4_dup_u64, vld4_dup_f64, vld4_dup_s8 vld4_dup_p8, vld4_dup_s16, vld4_dup_p16, vld4_dup_s32 vld4_dup_u8, vld4_dup_u16, vld4_dup_u32, vld4_dup_f32 vld4q_dup_s8, vld4q_dup_p8, vld4q_dup_s16, vld4q_dup_p16 vld4q_dup_s32, vld4q_dup_s64, vld4q_dup_u8, vld4q_dup_u16 vld4q_dup_u32, vld4q_dup_u64, vld4q_dup_f32, vld4q_dup_f64): Likewise. * config/aarch64/aarch64.md (define_c_enum unspec): Add UNSPEC_LD2_DUP, UNSPEC_LD3_DUP, UNSPEC_LD4_DUP. * config/aarch64/aarch64-simd-builtins.def (ld2r, ld3r, ld4r): New builtins. * config/aarch64/aarch64-simd.md (aarch64_simd_ld2rmode): New pattern. (aarch64_simd_ld3rmode): Likewise. (aarch64_simd_ld4rmode): Likewise. (aarch64_ld2rmode): New expand. (aarch64_ld3rmode): Likewise. (aarch64_ld4rmode): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-simd-builtins.def trunk/gcc/config/aarch64/aarch64-simd.md trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/arm_neon.h
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com --- Ah I see, then Dodji finally has the testcase he was looking for ;) Well, an equivalent one not using stdbool, which Jon is going to patch. Over the next week I will be mostly offline, unfortunately, please make sure Dodji sees it!
[Bug rtl-optimization/63637] New: CSE() on x86 asm()-s no longer working due to PR/60663 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63637 Bug ID: 63637 Summary: CSE() on x86 asm()-s no longer working due to PR/60663 fix Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at novell dot com Created attachment 33800 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33800action=edit example The attached example, derived after seeing x86 Linux'es this_cpu_read_stable() no longer getting CSE'd as expected, demonstrates the issue. 4.8.3 folded all four read_p() invocations and each pair of read_m(). Jakub pointed out that this is an effect of the fix for PR/60663 in connection with all x86 asm()-s getting two clobbers attached.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #9) however, we do not do it in the case of 'false' (because we do not think it should be a macro, but it actually is). Perhaps we should do it, is there a downside to it? The C++ standard explicitly forbids false from being a macro, it's a bug in stdbool.h and IMHO the front-end should not be changed to accommodate the bug.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- But the C standard requires that it is a macro. So, shouldn't just cstdbool #undef false and #undef true, or does C++ behave a particular behavior also for a header it doesn't own (stdbool.h)?
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, as stdbool.h documents, using it in C++ (apparently meant C++98) is a GNU extension, and for that I bet having those macros is desirable. And then there is C++11 [support.runtime]/8 that requires it is not done: The header cstdbool and the header stdbool.h shall not define macros named bool, true, or false. So, perhaps those macros should be conditional on C++ version?
GCC48/49 crash on fast floating point math in combination with -O3
Hi,
Looks like one of the -O3 optimising steps are broken:
cat EOF powfcrash.cpp
#include stdio.h
#include cmath
class test
{
public:
unsigned char y;
void testfn(unsigned char);
};
void
test :: testfn(unsigned char x)
{
y = x;
float fr = expf(powf(y / 127.0f, 0.5f) * logf(25000.0f)) + 40.0f;
printf(%f Result\n, fr);
}
int main()
{
class test test;
test.testfn(2.0);
return (0);
}
EOF
g++48 -O3 -ffast-math -Wall -Wextra powfcrash.cpp
powfcrash.cpp: In member function 'void test::testfn(unsigned char)':
powfcrash.cpp:12:1: internal compiler error: Segmentation fault: 11
test :: testfn(unsigned char x)
^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
g++48 -v
Using built-in specs.
COLLECT_GCC=g++48
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc48/gcc/x86_64-portbld-freebsd9.1/4.8.3/lto-wrapper
Target: x86_64-portbld-freebsd9.1
Configured with: ./../gcc-4.8.3/configure --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc48
--libexecdir=/usr/local/libexec/gcc48 --program-suffix=48
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc48/include/c++/
--with-ld=/usr/local/bin/ld --with-libiconv-prefix=/usr/local
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib
--with-ecj-jar=/usr/local/share/java/ecj-4.5.jar
--enable-languages=c,c++,objc,fortran,java --prefix=/usr/local
--mandir=/usr/local/man --infodir=/usr/local/info/gcc48
--build=x86_64-portbld-freebsd9.1
Thread model: posix
gcc version 4.8.3 (FreeBSD Ports Collection)
Thank you!
--HPS
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, that's what the patch I'm testing does. IMHO we should only define it for -std=gnu++98 and not any other -std mode, but I'll be conservative and leave it defined for -std=c++98 as well.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #15)
Yes, that's what the patch I'm testing does.
IMHO we should only define it for -std=gnu++98 and not any other -std mode,
but I'll be conservative and leave it defined for -std=c++98 as well.
Thus, the warning also needs fixing. Since the same behavior will occur if the
user directly or indirectly includes stdbool.h.
A testcase:
# 1 false.c
# 1 built-in
# 1 command-line
# 1 false.c
# 1 sys.h 1
# 2 sys.h 3
# 2 false.c 2
int * foo() {return
# 2 false.c 3
false
# 2 false.c
;}
# 1 nonsys.h 1
# 4 false.c 2
int * bar() {return false;}
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #16)
A testcase:
== sys.h ==
#pragma GCC system_header
#if defined false
#undef false
#endif
#define false false
== nonsys.h ==
#if defined false
#undef false
#endif
#define false false
== false.c ==
#include sys.h
int * foo() {return false;}
#include nonsys.h
int * bar() {return false;}
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org --- I assume that testcase is meant to be C++ (because it isn't valid C) but it's not valid C++ either: 17.6.4.3.1 [macro.names] A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #19) (In reply to Jonathan Wakely from comment #18) 17.6.4.3.1 [macro.names] A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords. (Also, why is this not an error with -std=c++11 -pedantic-errors?) In fact, if that quote appears in C++98, then it should be an error with -pedantic-errors in any C++ -std= mode.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #19 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #18) I assume that testcase is meant to be C++ (because it isn't valid C) but it's not valid C++ either: 17.6.4.3.1 [macro.names] A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords. This is exactly what G++'s stdbool.h is doing with -std=gnu++98 and -std=c++98. (Also, why is this not an error with -std=c++11 -pedantic-errors?)
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #38 from Rainer Orth ro at gcc dot gnu.org --- What's currently required to get Darwin/x86 to bootstrap again? I'm totally lost in this maze of PRs and patches. I've just tried r216667 plus the patch from PR 63620 on x86_64-apple-darwin14.0.0 and still run into ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::strstream' for architecture x86_64 when linking stage1 libstdc++. Rainer
[Bug sanitizer/63638] New: [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize=address)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638
Bug ID: 63638
Summary: [4.9 Regression] internal compiler error: in
asan_expand_check_ifn (with -fsanitize=address)
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: ai.azuma 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
Created attachment 33802
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33802action=edit
Output of -v option and preprocessed file
The following code causes an ICE on GCC 4.9.2 20141022 with -fsanitize=address.
//
// string header is supposed to
// be required for memcpy, but
// there is an implicit built-in
// declaration.
//#includestring
struct S{
long d0, d1, d2, d3, d4, d5, d6;
};
struct S s[6];
int f()
{
struct S *p;
memcpy(p, s[2], sizeof(*p));
memcpy(p, s[1], sizeof(*p));
}
//
The above code successfully compiles on GCC 4.9.2 20141015 with
-fsanitize=address, so it seems a regression that has been introduced between
them. The reproducer originally comes from GMP 6.0.0a configure script.
[Bug rtl-optimization/63633] [avr] internal compiler error: unrecognizable insn with mult insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- Created attachment 33801 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33801action=edit C test case that also generates wrong code
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #39 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Rainer Orth from comment #38) What's currently required to get Darwin/x86 to bootstrap again? I'm totally lost in this maze of PRs and patches. I've just tried r216667 plus the patch from PR 63620 on x86_64-apple-darwin14.0.0 and still run into ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::strstream' for architecture x86_64 when linking stage1 libstdc++. Rainer You should apply patch from comment 15 as well. It is still under review: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #19) This is exactly what G++'s stdbool.h is doing with -std=gnu++98 and -std=c++98. stdbool.h is a header which is C++ standardese for a standard library header. The rule only applies to user code, not std::lib headers. In your testcase sys.h is OK but nonsys.h is not. Although you can argue that since stdbool.h is not defined by the C++98 standard it is not a header and must not define the macro in __STRICT_ANSI__ mode. (Also, why is this not an error with -std=c++11 -pedantic-errors?) Because noone has ever implemented the diagnostic. Note that it only applies to user-code that includes a header so it's OK to define macros using the names of keywords as long as you never include a standard header. That makes it a bit more complicated to implement the diagnostic.
[Bug sanitizer/63638] [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize=address)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638 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 --- Created attachment 33803 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33803action=edit Proposed patch Thanks, I was aware of this problem. For GCC 5.0 Maxim is going to fix this with his dont-sanitize-builtins patch (currently reviewed in gcc-patches). Here is a trivial patch for 4.9 but I only had time to perform short regtesting (make check RUNTESTFLAGS=asan.exp).
[Bug sanitizer/63638] [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize=address)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Looks good, but please include the testcase for the testsuite (you can use __builtin_memcpy or declare extern #ifdef __cplusplus C #endif void *memcpy (void *, const void *, __SIZE_TYPE__); ), the testcase should go to trunk too.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #39 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Rainer Orth from comment #38) [...] You should apply patch from comment 15 as well. It is still under review: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html Even with this, the illegal text reloc error remains. May be a Mac OS X 10.10 thing, though? Rainer
[Bug sanitizer/63638] [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize=address)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Attachment #33803|0 |1 is obsolete|| --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Created attachment 33804 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33804action=edit Update patch Done. Should I send to gcc-patches now or wait until full bootstrap succeds (this will have to wait until Monday)?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) --- Comment #39 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Rainer Orth from comment #38) [...] You should apply patch from comment 15 as well. It is still under review: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html Even with this, the illegal text reloc error remains. May be a Mac OS X 10.10 thing, though? Rainer That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed.
[Bug tree-optimization/63595] [5.0 Regression] Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595 --- Comment #7 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Martin Liška from comment #6) There's patch I've been testing: diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c index d1238a4..7456fec 100644 --- a/gcc/ipa-icf.c +++ b/gcc/ipa-icf.c @@ -869,6 +869,12 @@ sem_function::compare_phi_node (basic_block bb1, basic_block bb2) phi1 = gsi_stmt (si1); phi2 = gsi_stmt (si2); + tree phi_result1 = gimple_phi_result (phi1); + tree phi_result2 = gimple_phi_result (phi2); + + if (!m_checker-compare_operand (phi_result1, phi_result2)) + return return_false_with_msg (PHI results are different); + size1 = gimple_phi_num_args (phi1); size2 = gimple_phi_num_args (phi2); I noticed you committed this as r216662 so gave it a try. 254.gap passes now but 447.dealII still segfaults and has the same code as described in Comment 4.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) [...] That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed. Adding --with-arch=core2 --with-cpu=core2 didn't make any difference. Rainer
[Bug sanitizer/63638] [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize=address)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Yury Gribov from comment #3) Created attachment 33804 [details] Update patch Done. Should I send to gcc-patches now or wait until full bootstrap succeds (this will have to wait until Monday)? Patch preapproved, please add PR sanitizer/63638 to the ChangeLog entries though. Feel free to post it now.
[Bug c++/60304] Including atomic disables -Wconversion-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304 --- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #21) (In reply to Manuel López-Ibáñez from comment #19) This is exactly what G++'s stdbool.h is doing with -std=gnu++98 and -std=c++98. stdbool.h is a header which is C++ standardese for a standard library header. The rule only applies to user code, not std::lib headers. In your testcase sys.h is OK but nonsys.h is not. We can drop the nonsys.h case. It is only testing that the no system_headers case also works (according to your other comment, it will be valid if no system_header is included). My point is that the fix cannot be only limited to tweaking stdbool.h, as long as any C++ mode still defines false as a macro.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #43 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #42) --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) [...] That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed. Adding --with-arch=core2 --with-cpu=core2 didn't make any difference. Rainer The core thing in comment 34 is patch in comment 33 applied on top of r216304. Most likely after r216304 someone broke darwin bootstrap again. So to test my changes I use revision r216304 with patch from commnet 33.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #44 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #43) (In reply to r...@cebitec.uni-bielefeld.de from comment #42) --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) [...] That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed. Adding --with-arch=core2 --with-cpu=core2 didn't make any difference. Rainer The core thing in comment 34 is patch in comment 33 applied on top of r216304. Most likely after r216304 someone broke darwin bootstrap again. So to test my changes I use revision r216304 with patch from commnet 33. there were at one point this week 4 concurrent bootstrap breaks on dariwn. this PR. the ipa-icf series requiring non-weak aliases and the iconv dep on libcpp. I don't know how many of those have been fixed so far - but I suspect that not all have. Unfortunately, not able to be more explict right now.
[Bug c/56980] C pretty-printer does not handle well pointer to typedef of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Fri Oct 24 16:29:56 2014 New Revision: 216674 URL: https://gcc.gnu.org/viewcvs?rev=216674root=gccview=rev Log: PR c/56980 * c-pretty-print.c (c_pretty_printer::simple_type_specifier): Don't print struct/union/enum for typedefed names. * gcc.dg/pr56980.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56980.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-pretty-print.c trunk/gcc/testsuite/ChangeLog
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #44 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #43) [...] there were at one point this week 4 concurrent bootstrap breaks on dariwn. this PR. the ipa-icf series requiring non-weak aliases and the iconv dep on libcpp. I don't know how many of those have been fixed so far - but I suspect that not all have. Unfortunately, not able to be more explict right now. Thanks for the update. As I said, I'd completely lost track of what's going on here. I'm now testing the rev before Evgeny's patch to check if that bootstraps on 10.10. If not, we may have yet another issue here. Rainer
[Bug c/56980] C pretty-printer does not handle well pointer to typedef of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56980 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #46 from Jeffrey A. Law law at redhat dot com --- Glad I'm not the only one struggling to track everything that's breaking on Darwin!
[Bug tree-optimization/63185] Improve DSE with branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
Another example:
#include time.h
void f(){
const int n=114;
double a[n];
double b[n];
double c[n];
__builtin_memset(a,0,n);
__builtin_memset(b,0,n);
__builtin_memset(c,0,n);
for(int i=0;in;++i)
c[i]=a[i]+b[i];
time(0);
}
If I make n a constant (using #define), DCE knows that c is not
ref_may_be_aliased (that test could probably be weakened) and removes almost
everything. We don't replace alloca_with_align with an array because the size
is larger than 256 (with a more limited scope the limit would even be 25...).
DSE is likely confused by the loop. And PRE and others don't know that a[i] is
always 0. (llvm removes everything but the final call)
[Bug target/63639] New: m32c cond.md cond_to_int uses -1 for lt and gt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63639 Bug ID: 63639 Summary: m32c cond.md cond_to_int uses -1 for lt and gt Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jon at beniston dot com The m32c cond_to_int pattern uses (const_int -1) for both less than and greater than: (define_insn cond_to_int [(set (match_operand:HI 0 mra_qi_operand =Rqi) (if_then_else:HI (lt (reg:CC FLG_REGNO) (const_int 0)) (const_int -1) (if_then_else:HI (eq (reg:CC FLG_REGNO) (const_int 0)) (const_int 0) (const_int -1] Should the second of these be (const_int 1)?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- [...] I'm now testing the rev before Evgeny's patch to check if that bootstraps on 10.10. If not, we may have yet another issue here. I'm now in stage2 at rev 216153, so there's no 10.10 issue here. Rainer
[Bug ipa/63598] [5.0 Regression] ICE: in ipa_merge_profiles at ipa-utils.c:396
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63598 --- Comment #3 from dave.anglin at bell dot net --- I had a successful build by setting 'flag_ipa_icf_functions = 0' in pa_option_override. Dave
[Bug fortran/63640] New: move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 Bug ID: 63640 Summary: move_alloc memory leak Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Hi, The move_alloc intrisic has a memory leak, the object from doesn't seems to be deallocated. Here is a small test case with integer, but leaks also for dp. I'm using version 4.9.1 . Thanks. program testmv3 type bar integer, allocatable :: ia(:), ja(:) end type integer, allocatable :: ia(:), ja(:) type(bar), allocatable :: sm,sm2 allocate(sm) allocate(sm2) allocate(sm%ia(100),sm%ja(100)) allocate(sm2%ia(1000),sm2%ja(1000)) allocate(ia(100),ja(1000)) call move_alloc(ja,ia) call move_alloc(sm%ia,sm2%ia) call move_alloc(sm%ja,sm2%ja) end program testmv3 ==5438== HEAP SUMMARY: ==5438== in use at exit: 4,992 bytes in 5 blocks ==5438== total heap usage: 29 allocs, 24 frees, 25,211 bytes allocated ==5438== ==5438== 96 bytes in 1 blocks are definitely lost in loss record 1 of 5 ==5438==at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5438==by 0x40089A: MAIN__ (test_memleak.f90:9) ==5438==by 0x400F66: main (test_memleak.f90:20) ==5438== ==5438== 896 (96 direct, 800 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 5 ==5438==at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5438==by 0x4009A1: MAIN__ (test_memleak.f90:10) ==5438==by 0x400F66: main (test_memleak.f90:20) ==5438== ==5438== 4,000 bytes in 1 blocks are definitely lost in loss record 5 of 5 ==5438==at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5438==by 0x400DD7: MAIN__ (test_memleak.f90:13) ==5438==by 0x400F66: main (test_memleak.f90:20) ==5438== ==5438== LEAK SUMMARY: ==5438==definitely lost: 4,192 bytes in 3 blocks ==5438==indirectly lost: 800 bytes in 2 blocks ==5438== possibly lost: 0 bytes in 0 blocks ==5438==still reachable: 0 bytes in 0 blocks ==5438== suppressed: 0 bytes in 0 blocks
[Bug tree-optimization/63641] New: Invalid shift leads to incorrect code on 32-bit system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641
Bug ID: 63641
Summary: Invalid shift leads to incorrect code on 32-bit system
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Compile and run this program with -m32 -O2 on an x86 system.
#include stdio.h
int f (unsigned char) __attribute__ ((noinline));
int
f (unsigned char b)
{
if (0x0 = b b = 0x8)
goto L;
if (b == 0x0b)
goto L;
if (0x0e = b b = 0x1a)
goto L;
if (0x1c = b b = 0x1f)
goto L;
return 0;
L:
return 1;
}
int
main ()
{
printf (%d\n, f (' '));
}
The program should print 0. However, when compiled with -m32 -O2 with current
mainline (revision 216611) it prints 1.
The generated code for f is:
f:
0: 8b 4c 24 04 mov0x4(%esp),%ecx
4: 31 c0 xor%eax,%eax
6: 80 f9 20cmp$0x20,%cl
9: 77 0a ja 15 f+0x15
b: b8 ff c9 ff f7 mov$0xf7ffc9ff,%eax
10: d3 e8 shr%cl,%eax
12: 83 e0 01and$0x1,%eax
15: f3 c3 repz ret
The bug is obvious: when the value in %cl is 0x20, the shr does nothing. The
ja needs to be a jae.
[Bug tree-optimization/63641] Invalid shift leads to incorrect code on 32-bit system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #1 from Ian Lance Taylor ian at airs dot com --- I'm guessing that this change is the cause of the problem: 2014-10-17 Jakub Jelinek ja...@redhat.com PR tree-optimization/63464 * gimple.h (gimple_seq_discard): New prototype. * gimple.c: Include stringpool.h and tree-ssanames.h. (gimple_seq_discard): New function. * optabs.h (lshift_cheap_p): New prototype. * optabs.c (lshift_cheap_p): New function, moved from... * tree-switch-conversion.c (lshift_cheap_p): ... here. * tree-ssa-reassoc.c: Include gimplify.h and optabs.h. (reassoc_branch_fixups): New variable. (update_range_test): Add otherrangep and seq arguments. Unshare exp. If otherrange is NULL, use for other ranges array of pointers pointed by otherrangep instead. Emit seq before gimplified statements for tem. (optimize_range_tests_diff): Adjust update_range_test caller. (optimize_range_tests_xor): Likewise. Fix up comment. (extract_bit_test_mask, optimize_range_tests_to_bit_test): New functions. (optimize_range_tests): Adjust update_range_test caller. Call optimize_range_tests_to_bit_test. (branch_fixup): New function. (execute_reassoc): Call branch_fixup.
[Bug tree-optimization/63641] Invalid shift leads to incorrect code on 32-bit system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641 --- Comment #2 from Ian Lance Taylor ian at airs dot com --- Created attachment 33805 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33805action=edit sample patch This patch seems to fix the problem, and the new tests still pass. But I haven't done full testing and I'm not entirely sure whether this is the right approach.
[Bug sanitizer/63638] [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize=address)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638 --- Comment #5 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Fri Oct 24 20:15:37 2014 New Revision: 216677 URL: https://gcc.gnu.org/viewcvs?rev=216677root=gccview=rev Log: 2014-10-25 Yury Gribov y.gri...@samsung.com PR sanitizer/63638 * asan.c (enum asan_check_flags): Fixed ASAN_CHECK_LAST. * c-c++-common/asan/pr63638.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/asan/pr63638.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/asan.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/63641] Invalid shift leads to incorrect code on 32-bit system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-10-24
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
I'd say the right fix would be instead:
--- gcc/tree-ssa-reassoc.c2014-10-17 12:53:59.286321210 +0200
+++ gcc/tree-ssa-reassoc.c2014-10-24 22:38:55.762859480 +0200
@@ -2513,7 +2513,7 @@ optimize_range_tests_to_bit_test (enum t
{
tree high = wide_int_to_tree (TREE_TYPE (lowi),
wi::to_widest (lowi)
-+ prec - wi::clz (mask));
++ prec - 1 - wi::clz (mask));
operand_entry_t oe = (*ops)[ranges[i].idx];
tree op = oe-op;
gimple stmt = op ? SSA_NAME_DEF_STMT (op)
there is no need to build further trees, and the other use of high also wants
the one smaller value.
The thing is, bit 0 of mask is value lowi, if e.g. wi::clz(mask) is 0, then
it means the topmost bit of mask is set, so the highest value in the interval
is
lowi + prec - 1. If only lowest bit of mask would be set (not possible, at
least 3 ranges of bits need to be there), then wi::clz(mask) would be prec - 1
and we'd want high to be equal to lowi. Mask is never zero.
[Bug tree-optimization/63641] [5 Regression] Invalid shift leads to incorrect code on 32-bit system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Invalid shift leads to |[5 Regression] Invalid |incorrect code on 32-bit|shift leads to incorrect |system |code on 32-bit system --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Will also try to tweak testcase so that we have also something that fails on 64-bit targets. Is Monday ok to resolve this?
[Bug tree-optimization/63641] [5 Regression] Invalid shift leads to incorrect code on 32-bit system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641 --- Comment #5 from Ian Lance Taylor ian at airs dot com --- Monday is fine. Thanks.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #11 from Evandro e.menezes at samsung dot com --- (In reply to Wilco from comment #9) The performance cost is a much bigger issue than codesize. The problem is that when register pressure is high, the register allocator decides to allocate integer liveranges to FP registers and insert int-fp moves for every use/define (ie. you end up with far more moves than you would if it were spilled, so it is a bad thing even if int-fp moves are cheap). I committed a workaround (http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing the int-fp move cost. Can you try this and check the issue has indeed gone? You need -mcpu=cortex-a57. I believe that it pretty much is, after a cursory examination. The code size after the patch is back down about 2% for the test case above. Of note, the prolog and epilog are much smaller, because the FP registers don't have to be saved and restored anymore, and the stack frame shrank correspondingly. Do you have an idea of the performance impact of this patch?
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #12 from Evandro e.menezes at samsung dot com --- (In reply to Evandro from comment #11) Do you have an idea of the performance impact of this patch? At least in Dhrystone, it improved by over 2% on A57.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Wilco from comment #9) I committed a workaround (http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing the int-fp move cost. Can you try this and check the issue has indeed gone? You need -mcpu=cortex-a57. Note when I submitted ThunderX support I used a base of 2 instead of a base of 1 due to 2 being the default and all values are relative to that. This is mentioned in https://gcc.gnu.org/onlinedocs/gccint/Costs.html . In fact a value of 2 means reload will not look at the constraints of a move instruction. So I think the cortex* cpus should also re-base these values based on 2 being gpr-to-gpr value.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #14 from Evandro e.menezes at samsung dot com --- (In reply to Wilco from comment #10) Note currently it is not possible to use FP registers for spilling using the hooks - basically you still end up with int-fp moves for every definition and use (even when multiple uses are right next to each other), and rematerialization does not happen at all. Vladimir, I had also noticed that the hooks that you pointed me to didn't seem to work as documented. Are we missing anything?
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #15 from Wilco wdijkstr at arm dot com --- (In reply to Evandro from comment #12) (In reply to Evandro from comment #11) Do you have an idea of the performance impact of this patch? At least in Dhrystone, it improved by over 2% on A57. It was ~2% on SPECINT2k, ~3% on SPECFP2k. There were large gains on other benchmarks where the allocator had gone berserk on FP moves inside the hot loop. The removal of the redundant FP saves/restores in many functions helps as well.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #16 from Wilco wdijkstr at arm dot com --- (In reply to Andrew Pinski from comment #13) (In reply to Wilco from comment #9) I committed a workaround (http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing the int-fp move cost. Can you try this and check the issue has indeed gone? You need -mcpu=cortex-a57. Note when I submitted ThunderX support I used a base of 2 instead of a base of 1 due to 2 being the default and all values are relative to that. This is mentioned in https://gcc.gnu.org/onlinedocs/gccint/Costs.html . In fact a value of 2 means reload will not look at the constraints of a move instruction. So I think the cortex* cpus should also re-base these values based on 2 being gpr-to-gpr value. You mean only use multiples of 2? That's interesting as I've not seen that done elsewhere. Are these costs in any way related to real issue and latency cycles? Most targets have complex tables with all the exact latencies for every little uarch detail, but from what I've seen in the allocator these costs have almost no meaning. So did you find that setting the FP move cost so low actually works alright on ThunderX? I'd like to figure out a setting for the generic target that works out well across all AArch64 implementations.
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #17 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Wilco from comment #16) (In reply to Andrew Pinski from comment #13) (In reply to Wilco from comment #9) I committed a workaround (http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing the int-fp move cost. Can you try this and check the issue has indeed gone? You need -mcpu=cortex-a57. Note when I submitted ThunderX support I used a base of 2 instead of a base of 1 due to 2 being the default and all values are relative to that. This is mentioned in https://gcc.gnu.org/onlinedocs/gccint/Costs.html . In fact a value of 2 means reload will not look at the constraints of a move instruction. So I think the cortex* cpus should also re-base these values based on 2 being gpr-to-gpr value. You mean only use multiples of 2? That's interesting as I've not seen that done elsewhere. Are these costs in any way related to real issue and latency cycles? Most targets have complex tables with all the exact latencies for every little uarch detail, but from what I've seen in the allocator these costs have almost no meaning. Not always multiple of 2 though in the case of ThunderX they are multiple of twos. The costs are not really directly related to the latency cost but it is relative to one another. So I could have used 2, 3, 4 (meaning latency of 1, 2, 3) instead. I used the factor of 2 instead of 1 for ThunderX because 2 + 3 != 4 but rather 5. So did you find that setting the FP move cost so low actually works alright on ThunderX? I'd like to figure out a setting for the generic target that works out well across all AArch64 implementations. Yes it seems to at least on the things we have benchmarked but we have not done much big benchmarks like SPEC yet.
