[Bug sanitizer/63927] New: AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 Bug ID: 63927 Summary: AddressSanitizer painfully slow on ppc64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: trippels 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 Created attachment 34013 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34013action=edit testcase With the attached testcase, that measures the performance of different C++ containers, AddressSanitizer is very slow on ppc64. x86_64 is fine. For example: trippels@gcc2-power8 ~ % g++ -fsanitize=address -g -O2 bench.cpp trippels@gcc2-power8 ~ % ./a.out sizearray vector_pointvector_itersdeque listset multiset 10 15.79 13.85 13.14 26.04 232.16 132.72 266.89 ^C On x86_64: markus@x4 ~ % ./a.out sizearray vector_pointvector_itersdeque listset multiset 10 0.460.460.461.39 4.552.363.74 ...
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- The numbers above are seconds. Perf shows: 29.44% a.out libgcc_s.so.1 [.] uw_update_context_1 13.08% a.out libasan.so.2.0.0[.] __sanitizer::mem_is_zero(char const*, unsigned long) 11.40% a.out libgcc_s.so.1 [.] execute_cfa_program 5.61% a.out libpthread-2.18.so [.] pthread_mutex_unlock 5.26% a.out libc-2.18.so[.] memcpy 4.90% a.out libgcc_s.so.1 [.] _Unwind_IteratePhdrCallback 4.07% a.out libasan.so.2.0.0[.] __asan_region_is_poisoned 3.33% a.out libpthread-2.18.so [.] pthread_mutex_lock 2.51% a.out libgcc_s.so.1 [.] uw_frame_state_for 2.36% a.out libc-2.18.so[.] memset 1.53% a.out libasan.so.2.0.0[.] __interceptor_strlen 1.51% a.out libgcc_s.so.1 [.] read_encoded_value_with_base 1.38% a.out libasan.so.2.0.0[.] __asan_memcpy 0.95% a.out libasan.so.2.0.0[.] __asan_memset
[Bug ipa/63470] [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to David Binderman from comment #2) Test case available on request. since non of the PRs have a testcase yet, would be good, if only to be added to the testsuite.
[Bug sanitizer/63913] [5 Regression] ICE: verify_gimple failed: statement marked for throw, but doesn't with -fnon-call-exceptions -fsanitize=bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63913 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34014 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34014action=edit gcc5-pr63913.patch Untested fix. Guess we want it for 4.9 too, even when the verification doesn't catch that.
[Bug target/63910] [5 Regression] ICE: simplify_immed_subreg, at simplify-rtx.c:5519 with -mstringop-strategy=vector_loop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63910 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-18 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r210113 aka wide-int merge. Looking into this.
[Bug ipa/63470] [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 --- Comment #4 from David Binderman dcb314 at hotmail dot com --- Created attachment 34015 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34015action=edit gzipped C++ source code FTjackSupport.cpp:695:1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:300 0xa70ba9 estimate_edge_growth(cgraph_edge*) ../../src/trunk/gcc/ipa-inline.h:299 0xa70abe estimate_size_after_inlining(cgraph_node*, cgraph_edge*) ../../src/trunk/gcc/ipa-inline-analysis.c:3834 0x17e677c caller_growth_limits(cgraph_edge*) ../../src/trunk/gcc/ipa-inline.c:201 0x17e677c can_inline_edge_p(cgraph_edge*, bool, bool) ../../src/trunk/gcc/ipa-inline.c:371
[Bug ipa/63470] [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 --- Comment #5 from David Binderman dcb314 at hotmail dot com --- (In reply to David Binderman from comment #4) Created attachment 34015 [details] gzipped C++ source code FTjackSupport.cpp:695:1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:300 0xa70ba9 estimate_edge_growth(cgraph_edge*) ../../src/trunk/gcc/ipa-inline.h:299 0xa70abe estimate_size_after_inlining(cgraph_node*, cgraph_edge*) ../../src/trunk/gcc/ipa-inline-analysis.c:3834 0x17e677c caller_growth_limits(cgraph_edge*) ../../src/trunk/gcc/ipa-inline.c:201 0x17e677c can_inline_edge_p(cgraph_edge*, bool, bool) ../../src/trunk/gcc/ipa-inline.c:371 Flags -O2 -finline-functions required.
[Bug tree-optimization/54779] split FRAME variables back into pieces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54779 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Attachment #32249|0 |1 is obsolete|| --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Created attachment 34016 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34016action=edit Updated implementation For a 4.9-based compiler.
[Bug target/63910] [5 Regression] ICE: simplify_immed_subreg, at simplify-rtx.c:5519 with -mstringop-strategy=vector_loop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63910 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- The compiler trips: #2 0x00a8e290 in simplify_immed_subreg (outermode=OImode, op=0x2e7afda0, innermode=optimized out, byte=optimized out) at ../../gcc-svn/trunk/gcc/simplify-rtx.c:5519 5519gcc_assert (GET_MODE_PRECISION (outer_submode) (gdb) list 5514 buf |= (unsigned HOST_WIDE_INT)(*vp++ value_mask) i; 5515 5516tmp[u] = buf; 5517base += HOST_BITS_PER_WIDE_INT; 5518 } 5519gcc_assert (GET_MODE_PRECISION (outer_submode) 5520= MAX_BITSIZE_MODE_ANY_INT); 5521r = wide_int::from_array (tmp, units, 5522 GET_MODE_PRECISION (outer_submode)); 5523elems[elem] = immed_wide_int_const (r, outer_submode); trying to simplify (gdb) p debug_rtx (op) (const_vector:V8DI [ (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) (const_int 0 [0]) ]) to OImode. MAX_BITSIZE_MODE_ANY_INT is 128 in the above assert. gcc-4.9 generates movoi without problems: vmovdqa .LC0(%rip), %ymm0 # 26*movoi_internal_avx/2 [length = 9]
[Bug c++/63928] New: [5 Regression] use after free in cp/constexpr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63928 Bug ID: 63928 Summary: [5 Regression] use after free in cp/constexpr.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: jason at gcc dot gnu.org bootstrap-asan shows: ==69040==ERROR: AddressSanitizer: heap-use-after-free on address 0x0a8800353c88 at pc 0x10972e94 bp 0x3fffd9fbb510 sp 0x3fffd9fbb580 READ of size 8 at 0x0a8800353c88 thread T0 #0 0x10972e90 in cxx_eval_store_expression ../../gcc/gcc/cp/constexpr.c:2541 #1 0x10972e90 in cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2913 #2 0x1096e540 in cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2924 #3 0x1096d808 in cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2918 #4 0x1096e998 in cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:3188 #5 0x1096a684 in cxx_eval_call_expression ../../gcc/gcc/cp/constexpr.c:1329 #6 0x1096ebd8 in cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2834 #7 0x1097d4a8 in cxx_eval_outermost_constant_expr ../../gcc/gcc/cp/constexpr.c:3314 #8 0x1098723c in maybe_constant_value(tree_node*, tree_node*) ../../gcc/gcc/cp/constexpr.c:3427 #9 0x107e30f8 in finish_static_assert(tree_node*, tree_node*, unsigned int, bool) ../../gcc/gcc/cp/semantics.c:7046 #10 0x10658d94 in cp_parser_static_assert ../../gcc/gcc/cp/parser.c:12139 #11 0x106aa5a8 in cp_parser_member_declaration ../../gcc/gcc/cp/parser.c:20673 #12 0x1062f158 in cp_parser_member_specification_opt ../../gcc/gcc/cp/parser.c:20542 #13 0x1062f158 in cp_parser_class_specifier_1 ../../gcc/gcc/cp/parser.c:19734 #14 0x1062f158 in cp_parser_class_specifier ../../gcc/gcc/cp/parser.c:19970 #15 0x1062f158 in cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:14630 #16 0x10636e84 in cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:11864 #17 0x106a4038 in cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:11454 #18 0x106a53e0 in cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:11403 #19 0x106b2084 in cp_parser_declaration ../../gcc/gcc/cp/parser.c:11300 #20 0x106b290c in cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:11186 #21 0x106b45ec in cp_parser_namespace_body ../../gcc/gcc/cp/parser.c:16166 #22 0x106b45ec in cp_parser_namespace_definition ../../gcc/gcc/cp/parser.c:16147 #23 0x106b2254 in cp_parser_declaration ../../gcc/gcc/cp/parser.c:11288 #24 0x106b290c in cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:11186 #25 0x106b45ec in cp_parser_namespace_body ../../gcc/gcc/cp/parser.c:16166 #26 0x106b45ec in cp_parser_namespace_definition ../../gcc/gcc/cp/parser.c:16147 #27 0x106b2254 in cp_parser_declaration ../../gcc/gcc/cp/parser.c:11288 #28 0x106b290c in cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:11186 #29 0x106b45ec in cp_parser_namespace_body ../../gcc/gcc/cp/parser.c:16166 #30 0x106b45ec in cp_parser_namespace_definition ../../gcc/gcc/cp/parser.c:16147 #31 0x106b2254 in cp_parser_declaration ../../gcc/gcc/cp/parser.c:11288 #32 0x106b290c in cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:11186 #33 0x106b3980 in cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4101 #34 0x106b3980 in c_parse_file() ../../gcc/gcc/cp/parser.c:32197 #35 0x10a7a9fc in c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1039 #36 0x119d855c in compile_file ../../gcc/gcc/toplev.c:570 #37 0x101edb5c in do_compile ../../gcc/gcc/toplev.c:2040 #38 0x101edb5c in toplev::main(int, char**) ../../gcc/gcc/toplev.c:2137 #39 0x101f3098 in main ../../gcc/gcc/main.c:38 #40 0x3fff817e47a8 (/lib64/libc.so.6+0x447a8) 0x0a8800353c88 is located 200 bytes inside of 208-byte region [0x0a8800353bc0,0x0a8800353c90) freed by thread T0 here: #0 0x10291710 in __interceptor_free ../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:28 #1 0x10501d1c in xcallocatorhash_maptree_node*, tree_node*, default_hashmap_traits::hash_entry::data_free(hash_maptree_node*, tree_node*, default_hashmap_traits::hash_entry*) ../../gcc/gcc/hash-table.h:233 #2 0x10501d1c in hash_tablehash_maptree_node*, tree_node*, default_hashmap_traits::hash_entry, xcallocator, true::expand() ../../gcc/gcc/hash-table.h:1346 #3 0x10502220 in hash_tablehash_maptree_node*, tree_node*, default_hashmap_traits::hash_entry, xcallocator, true::find_slot_with_hash(tree_node* const, unsigned int, insert_option) ../../gcc/gcc/hash-table.h:1455 #4 0x10502220 in hash_maptree_node*, tree_node*, default_hashmap_traits::put(tree_node* const, tree_node* const) ../../gcc/gcc/hash-map.h:207 #5 0x109706e0 in cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:2888 #6 0x1096e5d0 in
[Bug target/63910] [5 Regression] ICE: simplify_immed_subreg, at simplify-rtx.c:5519 with -mstringop-strategy=vector_loop -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63910 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34017 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34017action=edit gcc5-pr63910.patch Untested fix.
[Bug ipa/63470] [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-11-18
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 test % cat test.ii
class A
{
public:
virtual bool m_fn1 ();
virtual const char **m_fn2 (int);
virtual int m_fn3 ();
};
class FTjackSupport : A
{
~FTjackSupport ();
bool m_fn1 ();
bool m_fn4 ();
const char **
m_fn2 (int)
{
}
int _inited;
int *_jackClient;
int _activePathCount;
}
* a;
void fn1 (...);
void fn2 (void *);
int fn3 (int *);
FTjackSupport::~FTjackSupport () { m_fn4 (); }
bool
FTjackSupport::m_fn1 ()
{
if (!_jackClient)
return 0;
for (int i=0; _activePathCount; ++i)
if (m_fn2 (i))
fn2 (a);
if (m_fn3 ())
fn2 (a);
if (fn3 (_jackClient))
fn1 (0);
}
bool
FTjackSupport::m_fn4 ()
{
if (_inited _jackClient)
{
m_fn1 ();
return 0;
}
}
markus@x4 test % g++ -c -O2 -finline-functions test.ii
test.ii:50:1: internal compiler error: in estimate_edge_growth, at
ipa-inline.h:300
}
^
0xb6e70d estimate_edge_growth
../../gcc/gcc/ipa-inline.h:299
0xb6e70d estimate_size_after_inlining(cgraph_node*, cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3835
0x1354db4 caller_growth_limits
../../gcc/gcc/ipa-inline.c:201
0x1354db4 can_inline_edge_p
../../gcc/gcc/ipa-inline.c:371
0x1356fa2 update_callee_keys
../../gcc/gcc/ipa-inline.c:1252
0x1358bfd inline_small_functions
../../gcc/gcc/ipa-inline.c:1834
0x1358bfd ipa_inline
../../gcc/gcc/ipa-inline.c:2198
0x1358bfd execute
../../gcc/gcc/ipa-inline.c:2568
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/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #18 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Lawrence Velázquez from comment #17) Hey Lawrence, do you have a copyright assignment in place with the FSF? If so, please submit your trunk patch to gcc-patc...@gcc.gnu.org for review. If not, ask on the g...@gcc.gnu.org list for the paperwork to be sent to you.
[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63764
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #4)
This specific ICE started with r217125.
But it was failing before that already:
trippels@gcc2-power8 ~ % test2.ii
void
fn1 ()
{
__attribute__ ((altivec (vector__))) float saijplus16
= (__attribute__ ((altivec (vector__))) float){ 0.0, 0.0, 0.0, 0.0 };
((__attribute__ ((altivec (vector__))) float) saijplus16)[0] = 0;
}
trippels@gcc2-power8 ~ % /home/trippels/gcc_bisect/usr/local/bin/gcc
-mcpu=power8 -O2 -c test2.ii
test2.ii: In function ‘void fn1()’:
test2.ii:7:1: internal compiler error: in execute_todo, at passes.c:1842
}
^
0x1088b0df execute_todo
../../gcc/gcc/passes.c:1842
Please submit a full bug report,
Will bisect this later.
Yeah, 4.6 20100620 rejects that (no support for vector array subscripts), 4.8
ICEs, don't have anything in between.
That said, if something regressed because of r217125, it better should be
analyzed what changed, because hopefully that change should affect only
-fcheck-pointer-bounds. If not, something went very wrong.
[Bug sanitizer/63802] UBSan doesn't catch misaligned access if address is 16-bytes (or more) aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 Andrey Ryabinin ryabinin.a.a at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrey Ryabinin ryabinin.a.a at gmail dot com --- Fixed
[Bug rtl-optimization/63917] [5 Regression] r217646 caused many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63917 --- Comment #3 from Zhenqiang Chen zhenqiang.chen at arm dot com --- Root cause: r217646 enhances ifcvt to handle cbranchcc4 instruction. But ifcvt does not check whether an insn will clobber CC or not, when moving it before the cbranchcc4 instruction. I will work out a patch to fix it.
[Bug c++/55992] constexpr static member function not recognised in templated using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55992 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- I see... So far I haven't been able to make much progress on c++/15272 itself, thus feel free to reassign.
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Yes, delayed folding fixes wrong-code/valid-code samples. For invalid-code I see with delayed folding the following error-messages: t_pr57335.C: In function 'int main()': t_pr57335.C:29:5: error: non-constant condition for static assertion static_assert(BitsOrderCheck().IsLsbBottom(), blah); ^ t_pr57335.C:29:47: in constexpr expansion of 'BitsOrderCheck().BitsOrderCheck::IsLsbBottom()' t_pr57335.C:29:5: error: accessing 'BitsOrderCheck::Data::bits' member instead of initialized 'BitsOrderCheck::Data::byte' member in constant expression Not sure if this is desired.
[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766 --- Comment #5 from Ilya Enkovich enkovich.gnu at gmail dot com --- I forgot to mention PR in a ChangeLog. Patch is in trunk: https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00707.html
[Bug sanitizer/63520] ICE: in get_biv_step, at loop-iv.c:824 with -fsanitize=undefined on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63520 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-18 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- This happens during bootstrap-ubsan on ppc64.
[Bug target/63764] [5 Regression] ICE: in verify_ssa, at tree-ssa.c:939
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63764
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
For the #c4 testcase, it is even unclear to me whether we shouldn't reject it.
typedef float V __attribute__((vector_size (4 * sizeof (float;
void
fn2 ()
{
V saijplus16 = (V) { 0.0, 0.0, 0.0, 0.0 };
((V) saijplus16)[0] = 0;
}
doesn't ICE (at least on x86_64) though,
void
fn3 ()
{
float __attribute__((vector_size (4 * sizeof (float saijplus16 = (float
__attribute__((vector_size (4 * sizeof (float) { 0.0, 0.0, 0.0, 0.0 };
((float __attribute__((vector_size (4 * sizeof (float) saijplus16)[0] =
0;
}
does. The difference is when
handling the (type) saijplus16 cast in build_c_cast.
In the ppc case and fn3 case, the type is the same, so we end up with
NON_LVALUE_EXPR of saijplus16. In the fn2 case with V typedef, the type is
different (saijplus16 has V type, the cast uses its main variant), so we end up
with VIEW_CONVERT_EXPR of saijplus16 instead. The VCE gets folded away, while
NON_LVALUE_EXPR remains. But in all cases the casts aren't valid lvalue.
Note, C++ ICEs on all the testcases.
IMHO either we need to reject it (but how to find out in the case of
build_c_cast that it originally was non-lvalue?), or we need to skip the
NON_LVALUE_EXPRs when marking the var as addressable and taking address of it.
[Bug c++/63928] [5 Regression] use after free in cp/constexpr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63928 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug middle-end/63926] [5 Regression] ICE in estimate_edge_growth, at ipa-inline.h:300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63926 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-11-18 CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Testcase?
[Bug sanitizer/63520] ICE: in get_biv_step, at loop-iv.c:824 with -fsanitize=undefined on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63520 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 --- Could someone please bisect this one? (My own bisecting stuff is broken at present.)
[Bug other/63929] New: GCC sets soft-float ABI even is specified -mfloat-abi=hard when compiling an assembler file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63929 Bug ID: 63929 Summary: GCC sets soft-float ABI even is specified -mfloat-abi=hard when compiling an assembler file. Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nataliia.koval at globallogic dot com I have a simple source : test.s -- .syntax unified .arch armv7-a .fpu vfpv3-d16 .thumb .filetest.c .globala .data .align2 .typea, %object .sizea, 4 a: .word2330 .section.note.GNU-stack,,%progbits --- Compile it: gcc -D_REENTRANT -DU_ATTRIBUTE_DEPRECATED= -O2 -g -march=armv7-a -mfloat-abi=hard -mthumb -mabi=aapcs-linux -Wall -ansi -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -Wno-long-long -c -DPIC -fPIC -o test.o test.s gcc -O2 -g -march=armv7-a -mfloat-abi=hard -mthumb -mabi=aapcs-linux -Wall -ansi -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -Wno-long-long -shared -Wl,-Bsymbolic -nodefaultlibs -nostdlib -o test.so test.o -Wl,-Bsymbolic So Flags is rewrited to 'soft-float': readelf -a test.so |grep Flags Flags: 0x5000200, Version5 EABI, soft-float ABI Key to Flags: If specify explicitly .eabi_attribute here: -- test1.s --- .syntax unified .arch armv7-a .eabi_attribute 28, 1 .fpu vfpv3-d16 .thumb .filetest.c .globala .data .align2 .typea, %object .sizea, 4 a: .word2330 .section.note.GNU-stack,,%progbits -- it will work correctly now: readelf -a test1.so |grep Flags Flags: 0x5000400, Version5 EABI, hard-float ABI Key to Flags:
[Bug rtl-optimization/63659] [4.8/4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] wrong |wrong code at -O2 and -O3 |code at -O2 and -O3 on |on x86_64-linux-gnu |x86_64-linux-gnu --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930 Bug ID: 63930 Summary: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: ludo at gnu dot org libgfortran/runtime/error.c uses exit (2) in a few places to handle run-time errors. I would suggest replacing these calls with abort (). The rationale is that using abort would make things more convenient for users: one could inspect the core dump, or, when running the program in GDB, directly get a prompt upon SIGABRT instead of having to resort to catch syscall exit_group. Thanks.
[Bug ada/63931] New: Ada libraries use 5.0 as LIB_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63931 Bug ID: 63931 Summary: Ada libraries use 5.0 as LIB_VERSION Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org Instead it should use 5 unless we want to bump it for every release from the branch. I see /usr/lib/libgnat-5.0.so but expect /usr/lib/libgnat-5.so
[Bug c++/57153] [C++11] tries to use copy constructor for in-class initialized member in default constructor of template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57153 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.9.1, 5.0 Resolution|--- |FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.1.
[Bug c++/63904] ICE when accessing array member of constexpr struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63904 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-18 Blocks||55004 Summary|ICE when acessing array |ICE when accessing array |member of constexpr struct |member of constexpr struct Ever confirmed|0 |1
[Bug ada/63931] Ada libraries use 5.0 as LIB_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63931 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||charlet at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Arnaud Charlet charlet at gcc dot gnu.org --- Not sure what you mean. Aren't you confusing minor and micro versions? We do want 5.0 like we had 4.9/4.8/4.7/... previously, so this looks as expected to me. And we'll want 5.1 once we've branched. In other words, we want to bump for each major release of GCC (really, each minor if you look at major.minor.micro). What we do not want is 5.0.0/5.0.1. Arno
[Bug c++/60771] static in-class constexpr const reference initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60771 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed by the commit which fixed c++/50473 (r217672). I'm adding the testcase and closing the bug.
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Assignee|jakub at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- The issue here is the induction variable is shared? bb 5: # _17 = PHI 0(2), _11(4) _6 = b[_17]; _7 = c[_17]; _8 = _6 + _7; a[_17] = _8; _10 = .omp_data_i_3(D)-i; _11 = _10 + 1; .omp_data_i_3(D)-i = _11; if (_11 = 999) goto bb 4; else goto bb 3; and we didn't apply store-motion to it: Memory reference 1: b[_17] Memory reference 2: c[_17] Memory reference 3: a[_17] Memory reference 4: .omp_data_i_3(D)-i ... Querying dependency of refs 4 and 1: dependent. Querying dependencies of ref 4 in loop 1: dependent I think the static chain never points to global decls thus we could special-case this. We could also treat members of the frame as non-allocated and thus not worry about trailing arrays and such. Unfortunately the .omp_data_i is a regular function parameter and not a static chain :/
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) The issue here is the induction variable is shared? Ah right, the testcase is clearly invalid. There is a data race on i, as well as data races on all the a[i] stores (because 4 different threads all do the same thing). Andi, did you mean #pragma omp parallel for num_threads(4) instead?
[Bug middle-end/63926] [5 Regression] ICE in estimate_edge_growth, at ipa-inline.h:300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63926 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #1) Testcase? as asked for at the last lines of the previous comment... is there any option that allows for source files and .gcda files to be moved to a different directory ? I see the ICE in the original dir, but not if I move the relevant files around. Having said this, this is most likely a dup of PR63470
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Ok, I think Tom had a similar patch for this but passing the .omp_data_i by effective reference (restrict qualified pointer and DECL_BY_REFERENCE) fixes this. Index: gcc/omp-low.c === --- gcc/omp-low.c (revision 217692) +++ gcc/omp-low.c (working copy) @@ -1517,7 +1517,8 @@ fixup_child_record_type (omp_context *ct layout_type (type); } - TREE_TYPE (ctx-receiver_decl) = build_pointer_type (type); + TREE_TYPE (ctx-receiver_decl) += build_qualified_type (build_pointer_type (type), TYPE_QUAL_RESTRICT); } /* Instantiate decls as necessary in CTX to satisfy the data sharing @@ -2006,6 +2007,7 @@ create_omp_child_function (omp_context * DECL_NAMELESS (t) = 1; DECL_ARG_TYPE (t) = ptr_type_node; DECL_CONTEXT (t) = current_function_decl; + DECL_BY_REFERENCE (t) = 1; TREE_USED (t) = 1; if (cilk_for_count) DECL_CHAIN (t) = DECL_ARGUMENTS (decl); there are more similar objects built, so the above may not fully optimize all cases.
[Bug c++/63904] ICE when accessing array member of constexpr struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63904 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- It seems to be related to constexpr.c:cxx_eval_vec_init_1 function. The line ' int max = tree_to_shwi (array_type_nelts (atype));' there should be changed into 'int max = (int) tree_to_uhwi (array_type_nelts (atype));'. Issue is that array_type_netls returns size_type node (which is unsigned) with UHWI_MAX as value. Means that on conversions the value won't fit into shwi. By reading value as unsigned and then later on casting it to signed (btw shouldn't we use here instead HOST_WIDE_INT?), we solve this issue.
[Bug c++/60771] static in-class constexpr const reference initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60771 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Nov 18 11:25:47 2014 New Revision: 217708 URL: https://gcc.gnu.org/viewcvs?rev=217708root=gccview=rev Log: 2014-11-18 Paolo Carlini paolo.carl...@oracle.com PR c++/60771 * g++.dg/cpp0x/constexpr-ref6.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ref6.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/60771] static in-class constexpr const reference initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60771 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 60771, which changed state. Bug 60771 Summary: static in-class constexpr const reference initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60771 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/63932] New: posible problem with allocatable character(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63932 Bug ID: 63932 Summary: posible problem with allocatable character(:) Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Dear All the following code seems to produce the wrong result with 4.9.2. thanks v cat test.f90 module mod type :: t character(:), allocatable :: c integer :: i contains procedure, pass :: get end type t type :: u character(:), allocatable :: c end type u contains subroutine get(this, a) class(t), intent(in) :: this character(:), allocatable, intent(out), optional :: a if(present(a)) a=this%c end subroutine get end module mod program test use mod type(t) :: a type(u) :: b a%c='soemthing' call a%get(a=b%c) write(*,*) b%c end program test gfortran-4.9.2 test.f90 ./a.out
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Richard Biener from comment #7) Ok, I think Tom had a similar patch for this but passing the .omp_data_i by effective reference (restrict qualified pointer and DECL_BY_REFERENCE) fixes this. Index: gcc/omp-low.c === --- gcc/omp-low.c (revision 217692) +++ gcc/omp-low.c (working copy) @@ -1517,7 +1517,8 @@ fixup_child_record_type (omp_context *ct layout_type (type); } - TREE_TYPE (ctx-receiver_decl) = build_pointer_type (type); + TREE_TYPE (ctx-receiver_decl) += build_qualified_type (build_pointer_type (type), TYPE_QUAL_RESTRICT); } /* Instantiate decls as necessary in CTX to satisfy the data sharing @@ -2006,6 +2007,7 @@ create_omp_child_function (omp_context * DECL_NAMELESS (t) = 1; DECL_ARG_TYPE (t) = ptr_type_node; DECL_CONTEXT (t) = current_function_decl; + DECL_BY_REFERENCE (t) = 1; TREE_USED (t) = 1; if (cilk_for_count) DECL_CHAIN (t) = DECL_ARGUMENTS (decl); there are more similar objects built, so the above may not fully optimize all cases. For the invalid testcase the DECL_BY_REFERENCE setting isn't needed and its positive effect on PTA could also be seen if using build_reference_type instead of build_pointer_type in the first hunk.
[Bug c++/60437] [C++11] Bogus error: no matching function for call to 'X::X(brace-enclosed initializer list)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60437 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-18 Ever confirmed|0 |1
[Bug c++/57153] [C++11] tries to use copy constructor for in-class initialized member in default constructor of template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57153 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.9.1
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
Valid testcase (well, assign sth useful to g...)
#define N 1000
int a[N], b[N], c[N];
main()
{
int i, g;
#pragma omp parallel for num_threads(4)
for (i = 0; i N; i++) {
a[i] = b[i] + c[i] + g;
}
}
in the OMP fn we fail to hoist the load of .omp_child_i-g out of the
loop and thus generate inferior code.
[Bug c++/63885] [5 Regression] ICE in static assert of constexpr forwarding xvalue container member rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63885 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-18 Summary|ICE in static assert of |[5 Regression] ICE in |constexpr forwarding xvalue |static assert of constexpr |container member rvalue |forwarding xvalue container |reference |member rvalue reference Ever confirmed|0 |1
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
Valid testcase (well, assign sth useful to g...)
#define N 1000
int a[N], b[N], c[N];
main()
{
int i, g;
#pragma omp parallel for num_threads(4)
for (i = 0; i N; i++) {
a[i] = b[i] + c[i] + g;
}
}
in the OMP fn we fail to hoist the load of .omp_child_i-g out of the
loop and thus generate inferior code.
And does making receiver_decl restrict and/or reference type help with that?
BTW, we probably should add some IPA omp pass that would try to constant
propagate across from GOMP_parallel*/GOMP_task* callers to the *.omp_fn.*
functions (or teach IPA-SRA to do that?).
[Bug middle-end/63766] [5 Regression] ICE: in gimple_predict_edge, at predict.c:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. Thanks, Ilya.
[Bug c++/60245] function with using defined parameter not accepted as constexpr parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Blocks||55004 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in mainline, I'm adding the testcase and closing the bug.
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- PowerPC is the only target with an abi that can backtrace correctly without a frame pointer so it should be easy to implement that. Even x86 is broken backtracking without a frame pointer.
[Bug rtl-optimization/63917] [5 Regression] r217646 caused many failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63917 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug sanitizer/63927] AddressSanitizer painfully slow on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63927 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Right, but it is a library change, so somebody has to code it up, test and push upstream first, then we can cherry-pick it.
[Bug ada/63931] Ada libraries use 5.0 as LIB_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63931 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-11-18 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- The next major version after GCC 5 will be GCC 6. Off the gcc-5-branch we will release GCC 5.1 (first actual GCC 5 release) and then GCC 5.2, GCC 5.3 similar to how with the previous numbering we had GCC 4.9.0, GCC 4.9.1, GCC 4.9.2.
[Bug c++/60245] function with using defined parameter not accepted as constexpr parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Nov 18 11:57:16 2014 New Revision: 217709 URL: https://gcc.gnu.org/viewcvs?rev=217709root=gccview=rev Log: 2014-11-18 Paolo Carlini paolo.carl...@oracle.com PR c++/60245 * g++.dg/cpp0x/constexpr-60245.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-60245.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/63933] New: Build stage1 with -O2 during bootstrap if host compiler is a recent gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63933 Bug ID: 63933 Summary: Build stage1 with -O2 during bootstrap if host compiler is a recent gcc version Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Currently gcc doesn't add any optimization level flags during stage1. This means that stage1 is build with the default -O0 and that results in a very slow compiler. Build times during stage2 are very high because of this. One solution would be to detect the host compiler and if it is a recent (maintained?) version of gcc, then build stage1 with -O2. I did some rough measurements on gcc112: With: ../gcc/configure --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++,fortran I get for the current default: make -j160 28473.74s user 481.93s system 2067% cpu 23:20.53 total Adding -O2 during stage1 almost halves the bootstrap time: make -j160 15233.80s user 446.17s system 1918% cpu 13:37.25 total
[Bug sanitizer/63813] [5 Regression][UBSAN] ICE in ubsan_type_descriptor, at ubsan.c:346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63813 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34018 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34018action=edit gcc5-pr63813.patch Untested fix.
[Bug c++/60245] function with using defined parameter not accepted as constexpr parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug ada/63931] Ada libraries use 5.0 as LIB_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63931 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- See https://gcc.gnu.org/develop.html#num_scheme
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 60245, which changed state. Bug 60245 Summary: function with using defined parameter not accepted as constexpr parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60245 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/58930] [C++11] Bogus error: converting to ... from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58940 has been marked as a duplicate of this bug. ***
[Bug c++/58940] [C++11] Bogus error: use of deleted function ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58940 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Yes, also already fixed. *** This bug has been marked as a duplicate of bug 58930 ***
[Bug sanitizer/63855] [5 Regression] ICE: SIGSEGV in ipa_comdats with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The ICE is in the ipa-comdats.c pass, on a decl that has been created by: #4 0x0122e121 in make_node_stat (code=FUNCTION_DECL) at ../../gcc/tree.c:951 #5 0x0123c20c in build_decl_stat (loc=7698, code=FUNCTION_DECL, name=identifier_node 0x71a0b688 _GLOBAL__sub_I_b, type=function_type 0x7188a0a8) at ../../gcc/tree.c:4521 #6 0x007b4473 in build_lang_decl_loc (loc=7698, code=FUNCTION_DECL, name=identifier_node 0x71a0b688 _GLOBAL__sub_I_b, type=function_type 0x7188a0a8) at ../../gcc/cp/lex.c:540 #7 0x007b4446 in build_lang_decl (code=FUNCTION_DECL, name=identifier_node 0x71a0b688 _GLOBAL__sub_I_b, type=function_type 0x7188a0a8) at ../../gcc/cp/lex.c:529 #8 0x00798cf3 in start_objects (method_type=73, initp=65535) at ../../gcc/cp/decl2.c:3319 #9 0x0079a388 in generate_ctor_or_dtor_function (constructor_p=true, priority=65535, locus=0x7fffe130) at ../../gcc/cp/decl2.c:3925 #10 0x0079a479 in generate_ctor_and_dtor_functions_for_priority (n=0x234b490, data=0x7fffe130) at ../../gcc/cp/decl2.c:3955 #11 0x018d00ff in splay_tree_foreach_helper (data=0x7fffe130, fn=0x79a42e generate_ctor_and_dtor_functions_for_priority(splay_tree_node, void*), node=0x234b490) at ../../libiberty/splay-tree.c:242 #12 splay_tree_foreach (sp=optimized out, fn=0x79a42e generate_ctor_and_dtor_functions_for_priority(splay_tree_node, void*), data=0x7fffe130) at ../../libiberty/splay-tree.c:566 #13 0x0079c8b7 in cp_write_global_declarations () at ../../gcc/cp/decl2.c:4657 #14 0x00f5f213 in compile_file () at ../../gcc/toplev.c:584 I don't see how the sanitizer could be at fault here, looks like an IPA bug to me instead.
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844
--- Comment #11 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 18 Nov 2014, jakub at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Richard Biener from comment #9)
Valid testcase (well, assign sth useful to g...)
#define N 1000
int a[N], b[N], c[N];
main()
{
int i, g;
#pragma omp parallel for num_threads(4)
for (i = 0; i N; i++) {
a[i] = b[i] + c[i] + g;
}
}
in the OMP fn we fail to hoist the load of .omp_child_i-g out of the
loop and thus generate inferior code.
And does making receiver_decl restrict and/or reference type help with that?
Yes.
BTW, we probably should add some IPA omp pass that would try to constant
propagate across from GOMP_parallel*/GOMP_task* callers to the *.omp_fn.*
functions (or teach IPA-SRA to do that?).
I think aggregate IPA-CP does that, IPA-SRA cannot as the function has
its address taken.
Richard.
[Bug bootstrap/63933] Build stage1 with -O2 during bootstrap if host compiler is a recent gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63933 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is on purpose and how do we not know if the original compiler does not miscompile stage1 at -O2 until it is too late. Closing as won't fix.
[Bug bootstrap/63933] Build stage1 with -O2 during bootstrap if host compiler is a recent gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63933 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-11-18 Resolution|WONTFIX |--- Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- We dont know, but we will eventually figure it out. It's a matter of documentation to try STAGE1_CFLAGS=-g. Not that we didn't have wrong-code bugs at -O0 ...
[Bug bootstrap/63933] Build stage1 with -O2 during bootstrap if host compiler is a recent gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63933 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Btw, non-GCC host compilers use their default optimization setting which is usually optimizing. We're only pessimizing our own GCC here...
[Bug c++/55443] ICE for some placement new expressions inside noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55443 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Nov 18 12:24:34 2014 New Revision: 217711 URL: https://gcc.gnu.org/viewcvs?rev=217711root=gccview=rev Log: 2014-11-18 Paolo Carlini paolo.carl...@oracle.com PR c++/55443 * g++.dg/cpp0x/noexcept26.C: New. * g++.dg/cpp0x/noexcept27.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept26.C trunk/gcc/testsuite/g++.dg/cpp0x/noexcept27.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/55443] ICE for some placement new expressions inside noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55443 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|jason at gcc dot gnu.org, | |paolo.carlini at oracle dot com| Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c++/60437] [C++11] Bogus error: no matching function for call to 'X::X(brace-enclosed initializer list)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60437
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Paul Pluzhnikov from comment #0)
Using current trunk
g++ (GCC) 4.9.0 20140305 (experimental)
g++ -c t.cc -std=c++11
t.cc: In function 'void f()':
t.cc:10:8: error: no matching function for call to 'X::X(brace-enclosed
initializer list)'
X x{1};
Could we also print something better than brace-enclosed initializer list?
The linker prints:
undefined reference to `X::X(std::initializer_listint)'
Changing the testcase slightly gives:
test.C:12:8: error: no matching function for call to ‘X::X(brace-enclosed
initializer list)’
X x{1};
^
test.C:12:8: note: candidates are:
test.C:7:3: note: X::X(std::initializer_listY)
X(std::initializer_listY init);
^
test.C:7:3: note: no known conversion for argument 1 from ‘int’ to
‘std::initializer_listY’
Is it really trying to convert to 'std::initializer_listY' from 'int' or from
'std::initializer_listint'?
[Bug rtl-optimization/63843] [5 Regression] wrong code generation at -O1 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63843 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34019 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34019action=edit gcc5-pr63843.patch Untested fix.
[Bug tree-optimization/61518] [5 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61518 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Assuming yes, the testcase is in the testsuite after all.
[Bug tree-optimization/63914] ICE in set_lattice_value, at tree-ssa-ccp.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63914 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Known to fail|5.0 | --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/63914] ICE in set_lattice_value, at tree-ssa-ccp.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63914 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Nov 18 13:03:46 2014 New Revision: 217712 URL: https://gcc.gnu.org/viewcvs?rev=217712root=gccview=rev Log: 2014-11-18 Richard Biener rguent...@suse.de PR tree-optimization/63914 * tree-ssa-ccp.c (canonicalize_value): Remove float value canonicalization. (valid_lattice_transition): Allow (partial) transition from NaN to non-NaN if !HONOR_NANS. (set_lattice_value): Check for valid lattice transitions only when checking is enabled. * gcc.dg/pr63914.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr63914.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #9 from boger at us dot ibm.com --- My question was: what is supposed to happen on fallback? Sounds like some code gets rebuilt and used instead?
[Bug tree-optimization/61042] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61042 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed by: Author: kyukhin Date: Thu Jun 5 10:24:22 2014 New Revision: 211263 URL: http://gcc.gnu.org/viewcvs?rev=211263root=gccview=rev Log: gcc/ PR tree-optimization/61319 * tree-if-conv.c (is_cond_scalar_reduction): Add missed check that stmt belongs to loop. gcc/testsuite/ * gcc.dg/torture/pr61319.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61391.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug c++/60437] [C++11] Bogus error: no matching function for call to 'X::X(brace-enclosed initializer list)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60437
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #1)
Could we also print something better than brace-enclosed initializer list?
Like what?
Clang's approach seems to be to issue the same diagnostic for ill-formed
initializations X(1) and X{1}, just saying no matching constructor for
initialization of 'X' which dodges the issue.
Is it really trying to convert to 'std::initializer_listY' from 'int' or
from 'std::initializer_listint'?
From int.
{1} is not a std::initializer_listint (but can be converted to it)
A brace-enclosed initializer list is not the same as a std::initializer_list.
[Bug c++/58102] rejects valid initialization of constexpr object with mutable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58102 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Nov 18 13:34:08 2014 New Revision: 217713 URL: https://gcc.gnu.org/viewcvs?rev=217713root=gccview=rev Log: PR c++/58102 * typeck2.c (store_init_value): Set it. * cp-tree.h (CONSTRUCTOR_MUTABLE_POISON): New. * constexpr.c (cxx_eval_outermost_constant_expr): Check it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-mutable2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck2.c
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844 --- Comment #12 from Andi Kleen andi-gcc at firstfloor dot org --- Yes should have been omp parallel for
[Bug c++/57335] internal compiler error: in cxx_eval_bit_field_ref, at cp/semantics.c:6977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57335 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Kai Tietz from comment #6) t_pr57335.C:29:5: error: accessing 'BitsOrderCheck::Data::bits' member instead of initialized 'BitsOrderCheck::Data::byte' member in constant expression Yes, that's the desired behavior for this testcase.
[Bug tree-optimization/63844] [4.8/4.9/5 Regression] open mp parallelization prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63844 --- Comment #13 from Andi Kleen andi-gcc at firstfloor dot org --- I think aggregate IPA-CP does that, IPA-SRA cannot as the function has its address taken. Perhaps that case (only passing address to gomp runtime) could be special cased in the escape analysis.
[Bug c++/56292] False positive for constexpr arithmetics (-Wconversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0, 4.9.1, 5.0 Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.0.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ktietz at gcc dot gnu.org --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- This is another one to fix with Kai's delayed folding work.
[Bug bootstrap/63933] Build stage1 with -O2 during bootstrap if host compiler is a recent gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63933 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org --- Perhaps using -Og (or -O1) if available? I actually like to use unoptimized stage1 gcc to debug things with gdb, The last time I checked the worst offenders were some of the C++ inlines not getting inlined, and especially the new RTL code very heavily relies on that. Perhaps just #define inline __attribute__((always_inline)) inline for stage1 would be good enough to fix the worst.
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731
--- Comment #10 from Yohei Ueda yohei at jp dot ibm.com ---
https://code.google.com/p/go/source/browse/src/net/lookup_unix.go#63
func lookupIP(host string) (addrs []IP, err error) {
addrs, err, ok := cgoLookupIP(host)
if !ok {
addrs, err = goLookupIP(host)
}
return
}
This code shows how fallback works. If cgoLookup returns ok == false, then
pure-Go goLookupIP is called.
When the netgo tag is set, ok is always false.
https://code.google.com/p/go/source/browse/src/net/cgo_stub.go#5
When the netgo tag is not set, ok is always true.
https://code.google.com/p/go/source/browse/src/net/cgo_unix.go#147
https://code.google.com/p/go/source/browse/src/net/cgo_unix.go#84
If cgoLookupIP can also return ok == false when no nss is available, goLookupIP
will be called. This is my first idea.
https://code.google.com/p/go/source/browse/src/net/cgo_unix.go#116
However, I realized that we cannot easily distinguish the not found errors.
getaddrinfo returns not found in both cases of invalid hostname lookups and
static binaries.
If cgoLookup returns ok == false even when an invalid host name is looked up
with nss available, goLookupIP also looks it up again, so IP lookup occurs
twice, and both fails with not found error. I don't think this is desired
behavior.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||kcc at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Short testcase for #c3:
int
foo (int x)
{
int v = 0;
switch (x)
{
case 11: v = 67; break;
case 12: v = 68; break;
case 13: v = 69; break;
}
return v;
}
int
bar (int x)
{
int v = 0;
switch (x)
{
case 18: v = 67; break;
case 19: v = 68; break;
case 20: v = 69; break;
}
return v;
}
int
main ()
{
return foo (11) - 67 + bar (19) - 68;
}
reports that there is an ODR violation, though:
1) there is no such thing as ODR in C or Fortran, I wonder how can you apply by
default something like that without letting the compiler to pass through the
language of the vars
2) I don't see how that is anything close to an ODR violation; there are two
vars, CSWTCH.1 and CSWTCH.3, which, sometimes because of compiler decision,
sometimes unified by linker, have the same beginning address. What does that
have to do with ODR? Each of the vars has different definition, but they are
read-only and not address taken, so they can share the data. GCC with
-fmerge-all-constants also merges many read-only constants, even addressable
ones, when they have the same content.
[Bug sanitizer/63520] ICE: in get_biv_step, at loop-iv.c:824 with -fsanitize=undefined on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63520 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Unfortunately during bisection another ICE pops up: decNumber.i: In function ‘fn1’: decNumber.i:9:9: internal compiler error: in expand_expr_real_1, at expr.c:9487 a -= 1; ^ 0x1038feab expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**) ../../gcc/gcc/expr.c:9487 0x104b4743 expand_expr ../../gcc/gcc/expr.h:453 0x104b4743 ubsan_expand_si_overflow_addsub_check(tree_code, gimple_statement_base*) ../../gcc/gcc/internal-fn.c:180 0x104b5883 expand_internal_call(gimple_statement_base*) ../../gcc/gcc/internal-fn.c:482 0x10277c9b expand_call_stmt ../../gcc/gcc/cfgexpand.c:2185 0x10277c9b expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3154 0x10277c9b expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3306 0x10279683 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5146 0x1027bb2b gimple_expand_cfg ../../gcc/gcc/cfgexpand.c:5712 0x1027bb2b execute ../../gcc/gcc/cfgexpand.c:5932 And because one cannot be sure if it hides the original ICE, there is no exact bisection result. The bug was introduced between r205684 (bad) to 205802 (good)
[Bug c++/57979] G++ accepts constant expression defined using floating point non-constexpr glvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- This was introduced by the fix for bug 21089; decay_conversion and convert_like_real shouldn't be pulling values out of variables that are not decl_const_var_p. The trick is fixing that without breaking the static initialization optimization that 21089 is about. I guess allowing maybe_constant_init to be more aggressive than *_constant_value is the way to approach this.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 58102, which changed state. Bug 58102 Summary: rejects valid initialization of constexpr object with mutable member https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58102 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58102] rejects valid initialization of constexpr object with mutable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58102 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|jason at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed for GCC 5.
[Bug c++/63934] New: [C++] internal compiler error: in adjust_temp_type, at cp/constexpr.c:1020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63934 Bug ID: 63934 Summary: [C++] internal compiler error: in adjust_temp_type, at cp/constexpr.c:1020 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org During a gcc arm build, I run into: ... In file included from /home/vries/local/arm2/src/gcc-mainline/libstdc++-v3/src/c++11/chrono.cc:26:0: /home/vries/local/arm2/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/libstdc++-v3/include/chrono:723:49: in constexpr expansion \ of 'std::chrono::duration_Rep, _Period::minlong long int, std::ratio1ll, 10ll ()' /home/vries/local/arm2/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/libstdc++-v3/include/chrono:725:66: in constexpr expansion \ of 'std::chrono::durationlong long int, std::ratio1ll, 10ll ((* std::chrono::duration_values_Rep::minlong long int()))' /home/vries/local/arm2/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/libstdc++-v3/include/chrono:725:66: internal compiler error: \ in adjust_temp_type, at cp/constexpr.c:1020 a clock's minimum duration cannot be less than its epoch); ^ 0x8548ac0 adjust_temp_type /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:1020 0x854a410 cxx_eval_call_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:1377 0x8550247 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2835 0x8550902 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2895 0x854f4ae cxx_eval_store_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2529 0x855098b cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2914 0x8550a5f cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2926 0x8550ad0 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2940 0x8549fe6 cxx_eval_call_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:1329 0x8550247 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2835 0x8550902 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2895 0x8550b78 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2958 0x8551337 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:3147 0x8551337 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:3147 0x8548df3 cxx_bind_parameters_in_call /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:1072 0x854996e cxx_eval_call_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:1235 0x8550247 cxx_eval_constant_expression /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:2835 0x8551e9f cxx_eval_outermost_constant_expr /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:3314 0x85526bf maybe_constant_value(tree_node*, tree_node*) /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:3427 0x84c3418 finish_static_assert(tree_node*, tree_node*, unsigned int, bool) /home/vries/local/arm2/src/gcc-mainline/gcc/cp/semantics.c:7046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [chrono.lo] Error 1 ... With gdb, we can see the type and temp arguments: ... (gdb) #5 0x08548ac1 in adjust_temp_type (type=0xf7b883c0, temp=0xf77faa50) at /home/vries/local/arm2/src/gcc-mainline/gcc/cp/constexpr.c:1020 1020 gcc_assert (scalarish_type_p (type)); (gdb) call debug_generic_expr (type) struct duration (gdb) call debug_generic_expr (temp) (struct duration * const) D.10458 ...
[Bug c++/63934] [C++] internal compiler error: in adjust_temp_type, at cp/constexpr.c:1020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63934 --- Comment #1 from vries at gcc dot gnu.org --- Configure line: ... Target: arm-none-eabi Configured with: /home/vries/local/arm2/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --enable-lto --with-newlib --disable-nls --prefix=install --with-headers=yes --with-sysroot=install/arm-none-eabi --with-gmp=obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpfr=obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpc=obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-isl=obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --with-cloog=obj/pkg-mainline-0-arm-none-eabi/fsf-mainline-0-arm-none-eabi.extras/host-libs-i686-pc-linux-gnu/usr --disable-libgomp --disable-libitm --disable-libatomic --disable-libssp --enable-poison-system-directories --with-build-time-tools=install/arm-none-eabi/bin --with-build-time-tools=install/arm-none-eabi/bin SED=sed ...
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- forwprop-29.c fails on x86_64-apple-darwin14, because it does not emit an error for line 21.
[Bug c++/57979] G++ accepts constant expression defined using floating point non-constexpr glvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979 --- Comment #5 from Ville Voutilainen ville.voutilainen at gmail dot com --- I think this should be put on hold, since EWG told CWG in Rapperswil that const floats should perform the same magic as const ints do, see http://open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#1826 which EWG suggested CWG to reopen and resolve.
[Bug c++/57979] G++ accepts constant expression defined using floating point non-constexpr glvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979 --- Comment #6 from Ville Voutilainen ville.voutilainen at gmail dot com --- In other words, EWG wants the standard to be changed so that GCC's behavior actually becomes conforming, as far as I understand the intent.
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 18 Nov 2014, fxcoudert at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- forwprop-29.c fails on x86_64-apple-darwin14, because it does not emit an error for line 21. It expects both functions to be inlined. Can't reproduce with darwin specials (-fPIC -fno-ipa-icf). Can you upload 088t.dom1 dump?
[Bug tree-optimization/63841] [4.8 Regression] Incorrect strlen optimization after complete unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63841 --- Comment #11 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Tue Nov 18 14:20:58 2014 New Revision: 217715 URL: https://gcc.gnu.org/viewcvs?rev=217715root=gccview=rev Log: 2014-11-18 Teresa Johnson tejohn...@google.com Backport from mainline and gcc-4_9 branch. 2014-11-13 Teresa Johnson tejohn...@google.com PR tree-optimization/63841 * tree-ssa-strlen.c (strlen_optimize_stmt): Ignore clobbers. 2014-11-13 Teresa Johnson tejohn...@google.com PR tree-optimization/63841 * testsuite/g++.dg/tree-ssa/pr63841.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/tree-ssa/pr63841.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-strlen.c
[Bug c++/63934] [C++] internal compiler error: in adjust_temp_type, at cp/constexpr.c:1020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63934 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 34020 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34020action=edit chrono.ii Reproduce: ... ./obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/gcc/xgcc -B ./obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/gcc/ -shared-libgcc -nostdinc++ -std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=chrono.lo -g -O2 -S chrono.ii ...
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 --- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- With -O2 -fno-ipa-icf, the expected error shows up. With only -O2, it does not. I attach the 088t.dom1 dump for both cases.
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Created attachment 34021 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34021action=edit dom1 dump with -O2
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 --- Comment #7 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Created attachment 34022 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34022action=edit dom1 dump with -O2 -fno-ipa-icf
