[Bug c++/45333] Include macros in instantiation backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333 --- Comment #4 from dodji at seketeli dot org 2011-10-20 08:57:06 UTC --- > So we can track the origin of the instantation to the macro definition, but > then we don't show where the macro is invoked from, which is shown without > -ftrack-macro-expansion. I think it should show both, like clang does Agreed. > Notice that in my ideal output, I also fixed the location given for the first > instantation to point to "set" (1:19) and not to the end of the line > (1:24). Agreed again. I suspect this is related to our (ab)use of the global input_location instead of relying on the precise location of the tokens we are dealing with. So I guess it'll take some iterations to generally get this right, as you know already.
[Bug target/50781] ICE: in expand_vec_perm_broadcast_1, at config/i386/i386.c:35998 with -mavx and __builtin_shuffle()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50781 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jakub Jelinek 2011-10-20 08:54:33 UTC --- This ought to be fixed on the current trunk.
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #10 from Jakub Jelinek 2011-10-20 08:42:55 UTC --- Certainly not right now, this isn't a kind of change that should be added in between 4.6.2-RC and 4.6.2. Maybe later.
[Bug c++/45333] Include macros in instantiation backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-20 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez 2011-10-20 08:32:40 UTC --- With -ftrack-macro-expansion we get: pr45333.cc: In instantiation of ‘void C::set(int) [with T = S]’: pr45333.cc:1:24: required from here pr45333.cc:15:21: error: no match for ‘operator=’ in ‘((C*)this)->C::t = x’ pr45333.cc:15:21: note: candidate is: pr45333.cc:3:8: note: S& S::operator=(const S&) pr45333.cc:3:8: note: no known conversion for argument 1 from ‘int’ to ‘const S&’ So we can track the origin of the instantation to the macro definition, but then we don't show where the macro is invoked from, which is shown without -ftrack-macro-expansion. I think it should show both, like clang does: pr45333.cc: In instantiation of ‘void C::set(int) [with T = S]’: pr45333.cc:1:19: instantiated from macro ZERO pr45333.cc:20:3: required from here pr45333.cc:15:21: error: no match for ‘operator=’ in ‘((C*)this)->C::t = x’ pr45333.cc:15:21: note: candidate is: pr45333.cc:3:8: note: S& S::operator=(const S&) pr45333.cc:3:8: note: no known conversion for argument 1 from ‘int’ to ‘const S&’ Notice that in my ideal output, I also fixed the location given for the first instantation to point to "set" (1:19) and not to the end of the line (1:24).
[Bug c++/45385] missing -Wconversion for method calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45385 --- Comment #4 from Paolo Carlini 2011-10-20 08:27:38 UTC --- Thanks a lot. If I understand correctly this is a regression affecting a very sensible warning which we want to fix for 4.7, at least. We should mark it as such.
[Bug c++/45333] Include macros in instantiation backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333
--- Comment #2 from dodji at seketeli dot org
2011-10-20 08:25:20 UTC ---
Yes, it's related. With the infrastructure that is in right now, the
results are not super for template instantiate backtraces though:
$ cat -n test.cc
1#define ZERO(c) c.set(0)
2
3struct S
4{
5 int a;
6 int b;
7};
8
9template
10class C
11{
12 T t;
13
14public:
15 void set(int x) { t = x; }
16};
17
18void foo(C &c)
19{
20 ZERO(c);
21}
22
23
24
$
When cc1plus -quiet -ftrack-macro-expansion ./test.cc yields:
test.cc: In instantiation of ‘void C::set(int) [with T = S]’:
test.cc:1:24: required from here
test.cc:15:21: erreur: no match for ‘operator=’ in ‘((C*)this)->C::t = x’
test.cc:15:21: note: candidate is:
test.cc:3:8: note: S& S::operator=(const S&)
test.cc:3:8: note: no known conversion for argument 1 from ‘int’ to ‘const
S&’
So it points to the spelling location (1:24) of the token involved in
the error message, rather than to the expansion point of the macro. I'd
like it to mention both, like it does for the C FE.
Beside fixing the various bootstrap breakages I have introduced, I'll
need to go through the template instantiation error message mechanics to
teach them how to use the new macro token tracking infrastructure, I
guess. :-)
At least we have the infrastructure now.
Thank you for the head-up.
[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app. -fvisibility=hidden does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818 --- Comment #8 from Paolo Carlini 2011-10-20 08:23:01 UTC --- Vincenzo, I agree about the name, yesterday had the same thought. Then we have the usual annoyances with configure options and switches, we normally don't want to just rename in order to not break build systems, scripts, etc. I'll see what we can do, ideally add an alias and deprecate the old one.
[Bug bootstrap/50801] macro location tracking patch set breaks bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 Ulrich Weigand changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #4 from Ulrich Weigand 2011-10-20 08:21:18 UTC --- I can confirm that this patch fixes the problem I was seeing on SPU as well.
[Bug c++/45385] missing -Wconversion for method calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45385 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez 2011-10-20 08:19:05 UTC --- There is a check in c-common.c:conversion_warning that tests for things generated by the compiler by looking for artificial operands. The implicit *this pointer is probably triggering here. One could test for *this or perhaps there is a better way to check for compiler-generated expressions (if you remove the check, you should trigger a regression in the testsuite).
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #9 from Paolo Carlini 2011-10-20 08:19:28 UTC --- Ah great. Then I wonder if at this point we couldn't even resolve this..
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #8 from Michael Matz 2011-10-20 08:14:45 UTC --- Andi, the patch you bisected transformed a pre-existing bug into a segfault. Reverting it wouldn't fix anything. You could try the stab-in-the-dark patch from PR50741, but if that doesn't help I don't see how to make progress here without somebody who sees the problem to go into gdb and do a 'p debug_tree(var)' on a cc1 that has enough debuginfo for var to still contain a useful value.
[Bug bootstrap/50801] macro location tracking patch set breaks bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 --- Comment #3 from dodji at seketeli dot org 2011-10-20 08:05:18 UTC --- Patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01821.html
[Bug debug/50806] New: dwarf2out crash: missing GTY?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50806 Bug #: 50806 Summary: dwarf2out crash: missing GTY? Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com Target: x86_64-unknown-linux-gnu Created attachment 25560 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25560 Fix. With custom patched dwarf2out.c I got a crash on memory mangled by the garbage collector. With patched GTY there the crash no longer happened - but I do not have a reproducer anymore, sorry if it is a bogus patch. The memory corrupted later was initially allocated and stored into mem_loc_result->dw_loc_oprnd1.v.val_loc. I do not think there is any other reference to it than that field with no GTY. GIT 33e7b55c2549d655d88ec64c06c51912d0d07527 gcc (GCC) 4.7.0 20111002 (experimental) 11900 mem_loc_result->dw_loc_oprnd1.v.val_loc = op0; (gdb) bt #0 mem_loc_descriptor (rtl=, mode=SImode, mem_mode=VOIDmode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:11900 #1 in loc_descriptor (rtl=, mode=SImode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12790 #2 in loc_descriptor (rtl=, mode=SImode, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12614 #3 in dw_loc_list_1 (loc=, varloc=, want_address=2, initialized=VAR_INIT_STATUS_INITIALIZED) at gcc/dwarf2out.c:12889 #4 in dw_loc_list (loc_list=, decl=, want_address=2) at gcc/dwarf2out.c:13145 #5 in loc_list_from_tree (loc=, want_address=2) at gcc/dwarf2out.c:13538 #6 in add_location_or_const_value_attribute (die=, decl=, cache_p=0 '\000', attr=DW_AT_location) at gcc/dwarf2out.c:15048 #7 in gen_formal_parameter_die (node=, origin=0x0, emit_name_p=1 '\001', context_die=) at gcc/dwarf2out.c:16804 #8 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19632 #9 in gen_subprogram_die (decl=, context_die=) at gcc/dwarf2out.c:17560 #10 in gen_decl_die (decl=, origin=0x0, context_die=) at gcc/dwarf2out.c:19545 #11 in dwarf2out_decl (decl=) at gcc/dwarf2out.c:19919 #12 in dwarf2out_function_decl (decl=) at gcc/dwarf2out.c:19927 #13 in rest_of_handle_final () at gcc/final.c:4252 #14 in execute_one_pass (pass=0x4dbe120) at gcc/passes.c:2064 #15 in execute_pass_list (pass=0x4dbe120) at gcc/passes.c:2119 #16 in execute_pass_list (pass=0x4dbef00) at gcc/passes.c:2120 #17 in execute_pass_list (pass=0x4dbeea0) at gcc/passes.c:2120 #18 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420 #19 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803 #20 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862 #21 in cgraph_optimize () at gcc/cgraphunit.c:2133 #22 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310 #23 in c_write_global_declarations () at gcc/c-decl.c:9936 #24 in compile_file () at gcc/toplev.c:581 #25 in do_compile () at gcc/toplev.c:1925 #26 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001 #27 in main (argc=101, argv=) at gcc/main.c:36 It was later freed (watchpoint hit) by: (gdb) bt #0 __memset_sse2 () at ../sysdeps/x86_64/memset.S:333 #1 in poison_pages () at gcc/ggc-page.c:1845 #2 in ggc_collect () at gcc/ggc-page.c:1938 #3 in execute_todo (flags=2) at gcc/passes.c:1763 #4 in execute_one_pass (pass=0x4dbce80) at gcc/passes.c:2087 #5 in execute_pass_list (pass=0x4dbce80) at gcc/passes.c:2119 #6 in tree_rest_of_compilation (fndecl=) at gcc/tree-optimize.c:420 #7 in cgraph_expand_function (node=) at gcc/cgraphunit.c:1803 #8 in cgraph_expand_all_functions () at gcc/cgraphunit.c:1862 #9 in cgraph_optimize () at gcc/cgraphunit.c:2133 #10 in cgraph_finalize_compilation_unit () at gcc/cgraphunit.c:1310 #11 in c_write_global_declarations () at gcc/c-decl.c:9936 #12 in compile_file () at gcc/toplev.c:581 #13 in do_compile () at gcc/toplev.c:1925 #14 in toplev_main (argc=101, argv=) at gcc/toplev.c:2001 #15 in main (argc=101, argv=) at gcc/main.c:36 And later it crashed on the mangled memory.
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #8 from Jakub Jelinek 2011-10-20 07:57:10 UTC --- BTW, 4.6 numbers can be improved to the trunk numbers by applying http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179460 (aka a subset of Eric's r179165 change) - C++ references here prevent the vectorization of one of the loops.
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855 --- Comment #24 from rguenther at suse dot de 2011-10-20 07:43:44 UTC --- On Wed, 19 Oct 2011, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855 > > --- Comment #23 from Andrew Pinski 2011-10-19 > 19:10:38 UTC --- > The other way to handle this is to allow unswitch loops to handle non inner > loops which from what I can tell is a two line patch. Though unswitching is too late for loop invariant motion to work here.
[Bug target/49485] Performance problem with C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49485 --- Comment #7 from Jakub Jelinek 2011-10-20 07:36:40 UTC --- For me the trunk with vectorization is certainly faster than 4.3, it is true that 4.6 is slower. 4.3 -O3 -ffast-math 0m0.144s 4.3 -O3 -ffast-math -fno-tree-vectorize 0m0.167s 4.6 -O3 -ffast-math 0m0.194s 4.6 -O3 -ffast-math -fno-tree-vectorize 0m0.195s 4.6 -O3 -ffast-math -mavx 0m0.181s trunk -O3 -ffast-math 0m0.127s trunk -O3 -ffast-math -fno-tree-vectorize 0m0.176s trunk -O3 -ffast-math -mavx 0m0.071s
[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app. -fvisibility=hidden does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818 --- Comment #7 from vincenzo Innocente 2011-10-20 07:27:30 UTC --- no side effects for the time being. I've tried only small applications though. I would suggest to rename --disable-visibility --disable-std-visibility or similar as, applied to top level configure, it is not very informative about its semantics
