https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65628

--- Comment #2 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #1)
> Can you take a look Vladimir?
> There are also PR65629, PR65617 and PR65613, which might be dups.

Hi, Markus. I've looked at these bugs.  I can not get the same valdgrind
messages as you wrote.  But I get another one

==13149== Use of uninitialised value of size 8
==13149==    at 0xB6C7C7: process_bb_lives(basic_block_def*, int&, bool)
(lra-lives.c:936)
==13149==    by 0xB6D9A2: lra_create_live_ranges_1(bool, bool)
(lra-lives.c:1290)
==13149==    by 0xB6E25F: lra_create_live_ranges(bool, bool) (lra-lives.c:1355)
==13149==    by 0xB55087: lra(_IO_FILE*) (lra.c:2337)
==13149==    by 0xB136A9: do_reload (ira.c:5418)
==13149==    by 0xB136A9: (anonymous
namespace)::pass_reload::execute(function*) (ira.c:5589)
==13149==    by 0xBE5412: execute_one_pass(opt_pass*) (passes.c:2330)
==13149==    by 0xBE5875: execute_pass_list_1(opt_pass*) (passes.c:2382)
==13149==    by 0xBE5887: execute_pass_list_1(opt_pass*) (passes.c:2383)
==13149==    by 0xBE58C8: execute_pass_list(function*, opt_pass*)
(passes.c:2393)
==13149==    by 0x8E2E4B: cgraph_node::expand() (cgraphunit.c:1878)
==13149==    by 0x8E45F8: expand_all_functions (cgraphunit.c:2014)
==13149==    by 0x8E45F8: symbol_table::compile() (cgraphunit.c:2367)
==13149==    by 0x8E6137: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2444)
==

besides usual ones for sparseset code.  There is no such message on the trunk
dated by 20th March.

Between March 20 and March 29 I submitted only one patch for PR65407.  When I
revert the patch, I still have the same above message. So I don't think it is
RA fault.

Intteresting thing about the above message is that there is a sparseset code
nearby (2-3 lines away).  The sparseset always generates code for valgrind
because of its very specific code (a correct use of unitialized values).

So I suspect, given message should be about sparseset actually but valgrind
reports this about the code nearby because may be the GCC info fed to valgrind
was changed somewehere between March 21 and 29.  Although it is just my
speculations.

Reply via email to