[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
CC||tbsaunde at gcc dot gnu.org
--- Comment #5 from tbsaunde at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> Verified reverting the tree-ssa-ccp.c hunk of r242920 makes the ICE go away
> (then instead of _18 = _7 + _17; there is _18 = x2_3 + _17;
> (no idea why _7 hasn't actually been replaced with 0 but just with x2_3,
> though there is UB involved in the loop if x4[0] isn't 0 at the beginning)).
I think that is because match.pd doesn't have a pattern for x / 0, and nothing
else that would clean it up is run with -Og.
What happens is basically this, we first evaluate blocks in the order 2 4 5 3
4. So we first add _7 = 0, _15 = {0, 0, 0, 0}, _16 = 0, and _18 = _17 to the
latice. Then when we evaluate block 3 we set x2_4 to varying, and leave x3_2
as 0. Then we meet x2_4 and 0 and set _7 = x2_4 in the latice. Then when we
try and evaluate _15 = {_7, _7, _7, _7} we fail to meet the new value of {x2_4,
x2_4, x2_4, x2_4} and the old {0, 0, 0, 0} because set_latice_value doesn't
know how to handle meeting vector constants like that. Then evaluating _16 =
BIT_FIELD_REF<_15, 128, 0> we enter _16 = _7 into the latice because
gimple_simplify doesn't try to valueize _7. Then substitute_and_fold visits
the statement using _16 and replaces it with _7 and doesn't check if _7 should
also be replaced there.
It seems like there is basically 3 options for fixing this.
- make gimple_simplify try to simplify the ssa name it gets out of the vector
cst, but I guess the design is that should already be simplified.
- in get_constant_value if const_val[i] is a ssa name look up the value of that
ssa name. That seems simplest and least prone to other issues, but maybe there
is a need for all entries in const_val[] to be completely simplified?
- make set_latice_value and ccp_latice_meet correctly merge the 2 vector csts.
I'm not completely sure if that's even possible in all cases with vectors that
have different elements.
[Bug middle-end/77766] [7 Regression] wrong code at -O2 and -O3 in 64-bit mode on x86_64-linux-gnu (executable hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77766 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #3 from tbsaunde at gcc dot gnu.org --- appears to be fixed or latent as of r244205
[Bug target/77586] [7 Regression] ia64 target fails to build due to ICE triggered by -fself-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77586 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #2 from tbsaunde at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #1) > My offer at <https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01829.html> to > provide an untested patch to always enable TFmode support in libgcc on > ia64, if such an untested patch would be useful, stands. I think it would be useful for these targets to at least build in config-list.mk runs so the failure of each doesn't need to be manually checked. As for the vms targets there is at least an argument to be made that a configuration that builds but is not safe is less broken than a configuration that doesn't build at all. That said if nobody cares about vms ia64 can we just obsolete it?
[Bug target/69318] [6 regression] ICE in symtab_node::verify with -fabi-version=7 -Wabi=8 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69318
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
CC||tbsaunde at gcc dot gnu.org
--- Comment #2 from tbsaunde at gcc dot gnu.org ---
So, the direct cause is that we have two symbols
_Z18IndirectExternCallIPFviiEiEvT_T0_S3_ one for each of the template
instantiations.
Now the interesting bit is that if you compile this code as
g++ test.cc -m32 -fabi-version=7 (note there is no -Wabi=N)
then you get
cc1plus: error: ‘void IndirectExternCall(F, T, T) [with F = void
(__attribute__((stdcall, regparm(3))) *)(int, int); T = int]’ conflicts with
a previous declaration
test.cc:4:6: note: previous declaration ‘void IndirectExternCall(F, T, T)
[with F = void (*)(int, int); T = int]’
void IndirectExternCall(F f, T t1, T t2) { // { dg-warning "mangled name" }
^~
test.cc:4:6: note: a later -fabi-version= (or =0) avoids this error with a
change in mangling
which is a rather laime error, but at least it isn't an ICE I guess.
if you compile it as
g++ test.cc -m32 -fabi-version=7 -fabi-compat-version=8
then you get the same ICE as with -Wabi=8
So I suspect somehow the aliases from -fabi-compat-version are preventing us
from just erroring out.
[Bug middle-end/54809] gengtype ignore mark_hook in struct nested in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54809 --- Comment #3 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Wed Jan 13 02:51:11 2016 New Revision: 232309 URL: https://gcc.gnu.org/viewcvs?rev=232309=gcc=rev Log: remove mark_hook gty attribute gcc/ChangeLog: 2016-01-12 Trevor Saunders <tbsaunde+...@tbsaunde.org> PR middle-end/54809 * doc/gty.texi: Remove documentation of mark_hook. * gengtype.c (struct write_types_data): Remove code to support mark_hook attribute. (walk_type): Likewise. (write_func_for_structure): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/gty.texi trunk/gcc/gengtype.c
[Bug middle-end/43589] segmentation fault after using __attribute__((optimize()))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43589
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||tbsaunde at gcc dot gnu.org
Resolution|--- |WORKSFORME
Known to fail||
--- Comment #3 from tbsaunde at gcc dot gnu.org ---
can't reproduce with debian gcc {4.6,4.7,4.8,4.9,5.} or trunk. Seems this got
fixed at some point.
[Bug middle-end/60666] sese.c:536:11: warning: variable 'stmts' is used uninitialized whenever '||' condition is true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60666 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from tbsaunde at gcc dot gnu.org --- this code has changed a bunch (and moved to graphite-isl-ast-to-gimple.c) and the problem seems to have been fixed in the process.
[Bug c++/67533] internal compiler error: in build_call_a, at cp/call.c:372
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67533
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
CC||tbsaunde at gcc dot gnu.org
--- Comment #4 from tbsaunde at gcc dot gnu.org ---
minimal test case:
struct Tls {};
void _ZTW5mytls();
thread_local Tls mytls = mytls
It seems like the problem is the c++ fe doesn't expect _ZTW5mytls to be
prototyped by user code.
[Bug c++/44577] static local variables in class template methods are not optimized-away if not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44577 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from tbsaunde at gcc dot gnu.org --- gcc now removes class_template when optimizing so fixed.
[Bug middle-end/68366] [6 Regression] sdbout.c build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68366 --- Comment #1 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Mon Nov 16 02:28:15 2015 New Revision: 230402 URL: https://gcc.gnu.org/viewcvs?rev=230402=gcc=rev Log: PR 68366 - include emit-rtl.h in sdbout.c Some of the pa target macros rely on macros in emit-rtl.h and sdbout.c uses some of those macros, which means that sdbout.c needs to include emit-rtl.h. gcc/ChangeLog: 2015-11-15 Trevor Saunders <tbsaunde+...@tbsaunde.org> PR middle-end/68366 * sdbout.c: Include emit-rtl.h and function.h. Modified: trunk/gcc/ChangeLog trunk/gcc/sdbout.c
[Bug libobjc/24775] libobjc should not include GCC's target headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775 --- Comment #8 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Sat Nov 7 19:36:26 2015 New Revision: 229936 URL: https://gcc.gnu.org/viewcvs?rev=229936=gcc=rev Log: replace BITS_PER_UNIT with __CHAR_BIT__ in target libs libgcc/ChangeLog: 2015-11-07 Trevor Saunders <tbsaunde+...@tbsaunde.org> * config/visium/lib2funcs.c (__set_trampoline_parity): Use __CHAR_BIT__ instead of BITS_PER_UNIT. * fixed-bit.h: Likewise. * fp-bit.h: Likewise. * libgcc2.c (__popcountSI2): Likewise. (__popcountDI2): Likewise. * libgcc2.h: Likewise. * libgcov.h: Likewise. libobjc/ChangeLog: 2015-11-07 Trevor Saunders <tbsaunde+...@tbsaunde.org> PR libobjc/24775 * encoding.c (_darwin_rs6000_special_round_type_align): Use __CHAR_BIT__ instead of BITS_PER_UNIT. (objc_sizeof_type): Likewise. (objc_layout_structure): Likewise. (objc_layout_structure_next_member): Likewise. (objc_layout_finish_structure): Likewise. (objc_layout_structure_get_info): Likewise. Modified: trunk/libgcc/ChangeLog trunk/libgcc/config/visium/lib2funcs.c trunk/libgcc/fixed-bit.h trunk/libgcc/fp-bit.h trunk/libgcc/libgcc2.c trunk/libgcc/libgcc2.h trunk/libgcc/libgcov.h trunk/libobjc/ChangeLog trunk/libobjc/encoding.c
[Bug libobjc/24775] libobjc should not include GCC's target headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775 --- Comment #7 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Nov 3 22:43:22 2015 New Revision: 229727 URL: https://gcc.gnu.org/viewcvs?rev=229727=gcc=rev Log: remove usage of ROUND_TYPE_SIZE from encoding.c gcc got rid of this target macro in 2003, so it seems safe to assume the alternate path works fine on all targets. libobjc/ChangeLog: 2015-11-03 Trevor Saunders <tbsaunde+...@tbsaunde.org> PR libobjc/24775 * encoding.c (objc_layout_finish_structure): Remove usage of ROUND_TYPE_SIZE. Modified: trunk/libobjc/ChangeLog trunk/libobjc/encoding.c
[Bug libobjc/24775] libobjc should not include GCC's target headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775 --- Comment #4 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Sat Sep 12 22:19:00 2015 New Revision: 227710 URL: https://gcc.gnu.org/viewcvs?rev=227710=gcc=rev Log: remove STRUCT_VALUE macro This macro was converted to the TARGET_STRUCT_VALUE_RTX hook many years ago, however there are still some lingering definitions, and a use in libobjc. All the remaining definitions define the macro to 0, which libobjc treats the same as undefined, so it won't break anything else to have libobjc stop checking the macro. However it may be that this part of libobjc has been broken for a long time on targets that only define the hook, but that is a separate issue. gcc/ChangeLog: 2015-09-12 Trevor Saunders <tbsaunde+...@tbsaunde.org> * config/arc/arc.h: Remove define of STRUCT_VALUE. * config/lm32/lm32.h: Likewise. * config/mep/mep.h: Likewise. * config/visium/visium.h: Likewise. * system.h: Poison STRUCT_VALUE macro. libobjc/ChangeLog: 2015-09-12 Trevor Saunders <tbsaunde+...@tbsaunde.org> PR libobjc/24775 * sendmsg.c: Remove check of STRUCT_VALUE macro. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arc/arc.h trunk/gcc/config/lm32/lm32.h trunk/gcc/config/mep/mep.h trunk/gcc/config/visium/visium.h trunk/gcc/system.h trunk/libobjc/ChangeLog trunk/libobjc/sendmsg.c
[Bug libobjc/24775] libobjc should not include GCC's target headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775 --- Comment #5 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Sat Sep 12 22:19:06 2015 New Revision: 227711 URL: https://gcc.gnu.org/viewcvs?rev=227711=gcc=rev Log: remove unused defines from sendmsg.c libobjc/ChangeLog: 2015-09-12 Trevor Saunders <tbsaunde+...@tbsaunde.org> PR libobjc/24775 * sendmsg.c (gen_rtx): Remove macro. (gen_rtx_MEM): Likewise. (gen_rtx_REG): Likewise. (rtx): Likewise. Modified: trunk/libobjc/ChangeLog trunk/libobjc/sendmsg.c
[Bug libobjc/24775] libobjc should not include GCC's target headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775 --- Comment #6 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Sat Sep 12 22:19:11 2015 New Revision: 227712 URL: https://gcc.gnu.org/viewcvs?rev=227712=gcc=rev Log: stop including tm.h in sendmsg.c libobjc/ChangeLog: 2015-09-12 Trevor Saunders <tbsaunde+...@tbsaunde.org> PR libobjc/24775 * sendmsg.c (tm.h): Remove include. Modified: trunk/libobjc/ChangeLog trunk/libobjc/sendmsg.c
[Bug c++/65835] bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835 --- Comment #2 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Wed May 20 01:03:51 2015 New Revision: 223423 URL: https://gcc.gnu.org/viewcvs?rev=223423root=gccview=rev Log: fixup hash table descriptor in winnt.c gcc/ChangeLog: 2015-05-19 Trevor Saunders tbsaunde+...@tbsaunde.org PR c++/65835 * config/i386/winnt.c (struct wrapped_symbol_hasher): Change value_type to const char *. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt.c
[Bug target/66114] New: some indirect_jump patterns use operands[] in their condition when they shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66114 Bug ID: 66114 Summary: some indirect_jump patterns use operands[] in their condition when they shouldn't Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tbsaunde at gcc dot gnu.org Target Milestone: --- Target: fr30-* pa-* md.texi says that the condition in a named define_insn should not look at insn data. however the indirect_jump patterns for the pa and fr30 ports look at operands[]
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 --- Comment #8 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Feb 10 14:49:07 2015 New Revision: 220585 URL: https://gcc.gnu.org/viewcvs?rev=220585root=gccview=rev Log: cap frequency in make_forwarder_block In the testcase the block with problematic frequency has to incoming edges. Each edge has probability 1. The first edge's source bb has frequency 873/1, and the second has a frequency of 9409/1. So at least one of those is slightly high probably from some sort of rounding issue related to fixed point, but in any case make_forwarder_block should not create basic blocks with frequency greater than BB_FREQ_MAX. gcc/ PR tree-optimization/64326 * cfghooks.c (make_forwarder_block): Cap frequency of created basic block. Added: trunk/gcc/testsuite/gcc.dg/torture/pr64326.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfghooks.c
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from tbsaunde at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) So fixed? yes, just didn't get back to this tab yet
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 --- Comment #7 from tbsaunde at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #6) Hmm, the ICE seems to not reproduce for me :( I can reproduce with r220551, nothing special x86_64-linux-gnu with ./cc1 -O3 test.c
[Bug lto/64076] [4.9/5 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64076 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from tbsaunde at gcc dot gnu.org --- fixed
[Bug lto/64076] [4.9/5 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64076 --- Comment #3 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Feb 10 02:23:11 2015 New Revision: 220561 URL: https://gcc.gnu.org/viewcvs?rev=220561root=gccview=rev Log: Tolerate different definitions of symbols in lto gcc/ PR lto/64076 * ipa-visibility.c (update_visibility_by_resolution_info): Only assert when not in lto mode. Added: trunk/gcc/testsuite/g++.dg/lto/pr64076.H trunk/gcc/testsuite/g++.dg/lto/pr64076_0.C trunk/gcc/testsuite/g++.dg/lto/pr64076_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-visibility.c
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #23 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Feb 10 03:40:20 2015 New Revision: 220566 URL: https://gcc.gnu.org/viewcvs?rev=220566root=gccview=rev Log: Support gcov-tool without ftw.h gcc/ PR gcov-profile/61889 * config.in: regenerate. * configure.in: Likewise. * configure.ac: Check for ftw.h. * gcov-tool.c: Check for ftw.h before using nftw. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/gcov-tool.c
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 --- Comment #5 from tbsaunde at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #4) make_forwarder_block is definitely wrong on not capping. But I do not see how vectorizing can get us to a frequncy over FREQ_MAX? So probably some earlier bug in there too ok, I'll send a patch adding capping to make_forwarder_block. That's enough to make the testcase not ICE for me, do we care about trying to find the other bug assuming there is one? or does it make more sense to just hope it goes away when more frequency stuff uses sreal?
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #16 from tbsaunde at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #15) I think it is best to modify the remove_unreachable_nodes loop to first remove aliases before removing their target... how is this related? the target isn't removed at all in this case only the alias.
[Bug c++/64863] New: error for use of members of a forward declared enum is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64863
Bug ID: 64863
Summary: error for use of members of a forward declared enum is
poor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tbsaunde at gcc dot gnu.org
consider this test case
enum class foo;
int bar();
int main()
{
if (bar() foo::baz)
return 0;
return 1;
}
produces
test.cpp: In function ‘int main()’:
test.cpp:7:14: error: ‘baz’ is not a member of ‘foo’
if (bar() foo::baz)
^
which while true isn't terrible helpful. I'd think it would be better to say
only a forward declaration of foo has been seen, and to use members you need
the full definition.
[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from tbsaunde at gcc dot gnu.org --- fixed
[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 --- Comment #7 from tbsaunde at gcc dot gnu.org --- (In reply to tbsaunde from comment #6) It seems like the right thing to do is make varpool_node::create_alias() set ref_list.references, does that seem correct? O.O that was for another bug.
[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #6 from tbsaunde at gcc dot gnu.org --- It seems like the right thing to do is make varpool_node::create_alias() set ref_list.references, does that seem correct?
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #12 from tbsaunde at gcc dot gnu.org --- So, what is here is: emutls calls varpool_node::create_alias(decl(emutls_v.bar), decl(emutls_v.foo)) which sets alias = true and alias_target = node(emutls_v.foo) on the node for emutls_v.bar, however it does not set up ref_list.references on node(emutls_v.bar) to point at node(emutls_v.foo). Then during varification we call symtab_node::get_alias_target() which gets the alias from node(emutls_v.bar).ref_list.references but that crashes becauses references doesn't contain an element for the alias target.
[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 --- Comment #4 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Thu Jan 22 11:55:33 2015 New Revision: 219994 URL: https://gcc.gnu.org/viewcvs?rev=219994root=gccview=rev Log: make fold ignore decl_with_vis.symtab_node gcc/ PR middle-end/63325 * fold-const.c (fold_checksum_tree): Don't include expr.decl_with_vis.symtab_node in the checksum. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from tbsaunde at gcc dot gnu.org --- fixed
[Bug tree-optimization/64326] [5 Regression] ICE at -O3 on x86_64-linux-gnu in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #3 from tbsaunde at gcc dot gnu.org --- So, in cfghooks.c make_forwarder_block we redirect two edges to point at a bb, both edges have probability 1 (1) the first edge's src bb has freq 873, and the second 9409. So at least one of those is slightly high, and when we combine them we set the freq for dummy to 10282. Then later we copy that freq of 10282 and assert because that's not a sane frequency. Its not entirely clear to me if make_forwarder_block should handle this case by capping freq at 1, or if the bug is even earlier when those two initial frequencies are generated.
[Bug debug/57664] [4.8/4.9/5 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57664 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #6 from tbsaunde at gcc dot gnu.org --- seems to work now? maybe fixed by r209812?
[Bug middle-end/44982] [4.8/4.9/5 Regression] ICE in get_narrower, at tree.c:7832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 --- Comment #12 from tbsaunde at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #11) On Thu, 15 Jan 2015, tbsaunde at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #10 from tbsaunde at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Confirmed. hm, wfm, but it looks like the patch in comment 3 wasn't applied. Is there something to do here? Not sure if it was posted or tested - so maybe just do a bootstrap regtest with all languages and if that succeeds the patch (with the testcase) is preapproved. there is at least a large number of c++ test cases that fail with the patch. They all seem to be what you'd expect a file has errors before the new check, and more errors or warnings are expected to be emitted after the new check. It seems like some part of this setup is crazy, but I'm not really sure what to do about it at this point.
[Bug c++/63522] [4.8/4.9/5 Regression] ICE: unexpected expression 'ElementIndices' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63522 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #3 from tbsaunde at gcc dot gnu.org --- fixed?
[Bug middle-end/44982] [4.8/4.9/5 Regression] ICE in get_narrower, at tree.c:7832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #10 from tbsaunde at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Confirmed. hm, wfm, but it looks like the patch in comment 3 wasn't applied. Is there something to do here?
[Bug c++/64521] [4.9/5 Regression] ICE with -frepo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64521 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #2 from tbsaunde at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #1) I have a doc patch somewhere advising against using -frepo ... it's not necessary on modern systems and seems to have bit-rotted. should we just remove it? or is there a reason to keep it?
[Bug c++/31397] Useful compiler warning missing (virtual functions in derived classes used without 'virtual')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397 --- Comment #16 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Jan 6 02:02:47 2015 New Revision: 219213 URL: https://gcc.gnu.org/viewcvs?rev=219213root=gccview=rev Log: implement -Wsuggest-override c-family/ PR c++/31397 * c.opt (Wsuggest-override): New option. cp/ PR c++/31397 * class.c (check_for_override): Warn when a virtual function is an override not marked override. gcc/ PR c++/31397 * doc/invoke.texi: Document -Wsuggest-override. Added: trunk/gcc/testsuite/g++.dg/warn/Wsuggest-override.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/doc/invoke.texi
[Bug lto/64076] [4.9/5 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64076 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #2 from tbsaunde at gcc dot gnu.org --- what happens is this: testcase_2.o contains thunks to call s:: from vtables for each of x y and z. However testcase_2.C is compiled without t being a base so there's no thunk for t. So when testcase_1.C is compiled with t as a base of s we have an ironly thunk for t's vtable to call s::f and prevailing regular definitions of the other thunks. The result of that is triping the assert because we have one externally visible ironly thunk, and others that come from testcase_2.o
[Bug rtl-optimization/64157] [5.0 regression] FAIL: gcc.dg/torture/pr52429.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64157 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from tbsaunde at gcc dot gnu.org --- duping *** This bug has been marked as a duplicate of bug 64047 ***
[Bug target/64047] [5 Regression] ICE: Segmentation fault when compiling gcc.dg/torture/pr52429.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #2 from tbsaunde at gcc dot gnu.org --- *** Bug 64157 has been marked as a duplicate of this bug. ***
[Bug middle-end/63621] [5 Regression] ICE: error: Both section and comdat group is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63621 --- Comment #7 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Mon Dec 8 00:35:33 2014 New Revision: 218476 URL: https://gcc.gnu.org/viewcvs?rev=218476root=gccview=rev Log: don't ICE when section attribute is used on things in comdats gcc/ PR ipa/63621 * symtab.c (symtab_node::verify): Check for section attribute before asserting something isn't in a section and a comdat group. Added: trunk/gcc/testsuite/g++.dg/ipa/pr63621.C Modified: trunk/gcc/ChangeLog trunk/gcc/symtab.c
[Bug middle-end/63621] [5 Regression] ICE: error: Both section and comdat group is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63621 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #3 from tbsaunde at gcc dot gnu.org --- r217991 seems to work
[Bug sanitizer/63855] [5 Regression] ICE: SIGSEGV in ipa_comdats with -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63855 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from tbsaunde at gcc dot gnu.org --- dup of 61324 *** This bug has been marked as a duplicate of bug 61324 ***
[Bug ipa/61324] [5 Regression] ICE: SIGSEGV at ipa-comdats.c:321 with -fno-use-cxa-atexit -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61324 --- Comment #2 from tbsaunde at gcc dot gnu.org --- *** Bug 63855 has been marked as a duplicate of this bug. ***
[Bug middle-end/63544] hash_map ends in an infinite loop if overwritten mark_empty uses a different value than 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63544 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from tbsaunde at gcc dot gnu.org --- fixed in r217868
[Bug middle-end/39419] internal compiler error: Segmentation fault In function ‘void std::sort_heap'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39419 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #4 from tbsaunde at gcc dot gnu.org --- works on a variety of versions here too, I'm assuming this got fixed at some pointand calling it wfm
[Bug ipa/61602] [5 Regression] ICE in lto1 on x86_64-linux-gnu in ipa_single_use, at ipa.c:1257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61602
tbsaunde at gcc dot gnu.org changed:
What|Removed |Added
CC||tbsaunde at gcc dot gnu.org
--- Comment #4 from tbsaunde at gcc dot gnu.org ---
So, during the single use pass we have 3 variables in symtab a, b and d.
a-ref_list.referring is empty so the map doesn't contain an entry for a. So
single_use_map is only { b- main, d - main } and we assert because
single_use_map.get(a) returns NULL.
However I'm not sure if the problem is the assert being incorrect or if
a.ref_list.referring should contain main.
[Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from tbsaunde at gcc dot gnu.org --- both 4.6 and 4.7 are unmaintained at this point, and this seems like reasonable behavior anyway.
[Bug lto/51642] Weak variable reference triggers ICE with -flto option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #5 from tbsaunde at gcc dot gnu.org --- 4.6 branch is closed
[Bug bootstrap/63516] New: error when trying to build without a c++ compiler could be better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63516 Bug ID: 63516 Summary: error when trying to build without a c++ compiler could be better Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tbsaunde at gcc dot gnu.org CC: segher at gcc dot gnu.org If for whatever reason you miss the requirement that you need a c++ compiler to build the first error you hit is checking for uintmax_t... yes checking for uintptr_t... yes checking for int64_t underlying type... long long configure: error: error verifying int64_t uses long long Makefile:4042: recipe for target 'configure-stage1-gcc' failed make[2]: *** [configure-stage1-gcc] Error 1 make[2]: Leaving directory '/src/gcc-opt' Makefile:21799: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 Which happens because that configure check happens to use C++. It seems to me explicitly checking for a C++ compiler would be better. This is reproducably by putting a dummy g++ in your path that just exits 1. make[1]: Leaving directory '/src/gcc-opt'
[Bug pch/63429] [Regression 5] Cannot build compiler with --enable-gather-detailed-mem-stats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63429 --- Comment #1 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Sat Oct 4 13:29:26 2014 New Revision: 215888 URL: https://gcc.gnu.org/viewcvs?rev=215888root=gccview=rev Log: Fix dupplicate declaration of ggc_realloc in gencondmd If vec.h is included before ggc.h it forward declares ggc_realloc with defaulted arguments. This means ggc.h can not be included later because it would lead to a second declaration of ggc_realloc with defaulted arguments. In generator programs vec.h can not include ggc.h because it may not exist yet. So generator programs must make sure they include ggc.h before anything that includes vec.h. gcc/ChangeLog: 2014-10-04 Trevor Saunders tsaund...@mozilla.com PR pch/63429 * genconditions.c: Directly include ggc.h before rtl.h. Modified: trunk/gcc/ChangeLog trunk/gcc/genconditions.c
[Bug c++/61945] tree check fail with -Woverloaded-virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61945
--- Comment #1 from tbsaunde at gcc dot gnu.org ---
minimized test case
class A
{
virtual void NotifyDialMMISuccess();
};
class : A
{
template 0 void NotifyDialMMISuccess();
};
ICEs with g++ -Woverloaded-virtual -std=gnu++11
[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63298 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #1 from tbsaunde at gcc dot gnu.org --- if it helps I see this when building TestFile in firefox (I gues you to not use --disable-tests)
[Bug pch/63229] [5.0 Regression] FAIL: ./except-1.h -O0 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63229 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from tbsaunde at gcc dot gnu.org --- fixed
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #8 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Wed Jul 9 03:07:09 2014 New Revision: 212384 URL: https://gcc.gnu.org/viewcvs?rev=212384root=gccview=rev Log: playcate old gcc gcc/ PR bootstrap/61679 * hash-table.h: use hash_table::value_type instead of Descriptor::value_type in the return types of several methods. Modified: trunk/gcc/ChangeLog trunk/gcc/hash-table.h
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from tbsaunde at gcc dot gnu.org --- fixed
[Bug bootstrap/61598] [4.10 regression] fold-const.c:14755:37: error: no matching function for call to 'hash_tablepointer_hashtree_node ::find_slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61598 --- Comment #3 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Wed Jun 25 16:02:04 2014 New Revision: 211985 URL: https://gcc.gnu.org/viewcvs?rev=211985root=gccview=rev Log: fix checking=fold gcc/ PR bootstrap/61598 * fold-const.c (fold_checksum_tree): Use a hash_table of const tree_node * instead of tree_node *. (fold): Adjust. (print_fold_checksum): Likewise. (fold_check_failed): Likewise. (debug_fold_checksum): Likewise. (fold_build1_stat_loc): Likewise. (fold_build2_stat_loc): Likewise. (fold_build3_stat_loc): Likewise. (fold_build_call_array_loc): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug c/61612] trunk revision 211984 winnt.c ‘hash_table_c’ does not name a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612 --- Comment #1 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Wed Jun 25 16:36:49 2014 New Revision: 211986 URL: https://gcc.gnu.org/viewcvs?rev=211986root=gccview=rev Log: fix typo in winnt.c gcc/ PR c/61612 * config/i386/winnt.c (i386_find_on_wrapper_list): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt.c
[Bug bootstrap/61598] [4.10 regression] fold-const.c:14755:37: error: no matching function for call to 'hash_tablepointer_hashtree_node ::find_slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61598 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from tbsaunde at gcc dot gnu.org --- fixed
