diff mbox

condition decision based on uninitialized memory

Message ID 5481A6B7.6050103@suse.cz
State New
Headers show

Commit Message

Martin Liška Dec. 5, 2014, 12:36 p.m. UTC
Hello.

I've just spent some time hunting memory leaks related to my isolated branch.
Valgrind reports many following errors:

==13612== Conditional jump or move depends on uninitialised value(s)
==13612==    at 0xAC72A4: sparseset_bit_p (sparseset.h:147)
==13612==    by 0xAC72A4: sparseset_and_compl(sparseset_def*, sparseset_def*, sparseset_def*) (sparseset.c:190)
==13612==    by 0x9B296C: process_bb_lives(basic_block_def*, int&, bool) (lra-lives.c:885)
==13612==    by 0x9B394A: lra_create_live_ranges_1(bool, bool) (lra-lives.c:1264)
==13612==    by 0x9B426F: lra_create_live_ranges(bool, bool) (lra-lives.c:1329)
==13612==    by 0x99B4A3: lra(_IO_FILE*) (lra.c:2350)
==13612==    by 0x959B79: do_reload (ira.c:5391)
==13612==    by 0x959B79: (anonymous namespace)::pass_reload::execute(function*) (ira.c:5561)
==13612==    by 0xA22127: execute_one_pass(opt_pass*) (passes.c:2311)
==13612==    by 0xA225F5: execute_pass_list_1(opt_pass*) (passes.c:2363)
==13612==    by 0xA22607: execute_pass_list_1(opt_pass*) (passes.c:2364)
==13612==    by 0xA22648: execute_pass_list(function*, opt_pass*) (passes.c:2374)
==13612==    by 0x726F04: cgraph_node::expand() (cgraphunit.c:1773)
==13612==    by 0x727BCF: output_in_order(bool) (cgraphunit.c:2011)

Following patch just replaces XNEWVAR with XCNEWVAR and it solves all these errors.
Ready for trunk?

Thanks,
Martin

Comments

Jakub Jelinek Dec. 5, 2014, 1 p.m. UTC | #1
On Fri, Dec 05, 2014 at 01:36:07PM +0100, Martin Liška wrote:
> I've just spent some time hunting memory leaks related to my isolated branch.
> Valgrind reports many following errors:
> 
> ==13612== Conditional jump or move depends on uninitialised value(s)
> ==13612==    at 0xAC72A4: sparseset_bit_p (sparseset.h:147)
> ==13612==    by 0xAC72A4: sparseset_and_compl(sparseset_def*, sparseset_def*, sparseset_def*) (sparseset.c:190)
> ==13612==    by 0x9B296C: process_bb_lives(basic_block_def*, int&, bool) (lra-lives.c:885)
> ==13612==    by 0x9B394A: lra_create_live_ranges_1(bool, bool) (lra-lives.c:1264)
> ==13612==    by 0x9B426F: lra_create_live_ranges(bool, bool) (lra-lives.c:1329)
> ==13612==    by 0x99B4A3: lra(_IO_FILE*) (lra.c:2350)
> ==13612==    by 0x959B79: do_reload (ira.c:5391)
> ==13612==    by 0x959B79: (anonymous namespace)::pass_reload::execute(function*) (ira.c:5561)
> ==13612==    by 0xA22127: execute_one_pass(opt_pass*) (passes.c:2311)
> ==13612==    by 0xA225F5: execute_pass_list_1(opt_pass*) (passes.c:2363)
> ==13612==    by 0xA22607: execute_pass_list_1(opt_pass*) (passes.c:2364)
> ==13612==    by 0xA22648: execute_pass_list(function*, opt_pass*) (passes.c:2374)
> ==13612==    by 0x726F04: cgraph_node::expand() (cgraphunit.c:1773)
> ==13612==    by 0x727BCF: output_in_order(bool) (cgraphunit.c:2011)
> 
> Following patch just replaces XNEWVAR with XCNEWVAR and it solves all these errors.
> Ready for trunk?

No.  sparseset is intentionally uninitialized. If you build with valgrind
checking, sparseset is properly instrumented so that valgrind doesn't
complain, otherwise just ignore those.

	Jakub
Martin Liška Dec. 5, 2014, 3:09 p.m. UTC | #2
On 12/05/2014 02:00 PM, Jakub Jelinek wrote:
> On Fri, Dec 05, 2014 at 01:36:07PM +0100, Martin Liška wrote:
>> I've just spent some time hunting memory leaks related to my isolated branch.
>> Valgrind reports many following errors:
>>
>> ==13612== Conditional jump or move depends on uninitialised value(s)
>> ==13612==    at 0xAC72A4: sparseset_bit_p (sparseset.h:147)
>> ==13612==    by 0xAC72A4: sparseset_and_compl(sparseset_def*, sparseset_def*, sparseset_def*) (sparseset.c:190)
>> ==13612==    by 0x9B296C: process_bb_lives(basic_block_def*, int&, bool) (lra-lives.c:885)
>> ==13612==    by 0x9B394A: lra_create_live_ranges_1(bool, bool) (lra-lives.c:1264)
>> ==13612==    by 0x9B426F: lra_create_live_ranges(bool, bool) (lra-lives.c:1329)
>> ==13612==    by 0x99B4A3: lra(_IO_FILE*) (lra.c:2350)
>> ==13612==    by 0x959B79: do_reload (ira.c:5391)
>> ==13612==    by 0x959B79: (anonymous namespace)::pass_reload::execute(function*) (ira.c:5561)
>> ==13612==    by 0xA22127: execute_one_pass(opt_pass*) (passes.c:2311)
>> ==13612==    by 0xA225F5: execute_pass_list_1(opt_pass*) (passes.c:2363)
>> ==13612==    by 0xA22607: execute_pass_list_1(opt_pass*) (passes.c:2364)
>> ==13612==    by 0xA22648: execute_pass_list(function*, opt_pass*) (passes.c:2374)
>> ==13612==    by 0x726F04: cgraph_node::expand() (cgraphunit.c:1773)
>> ==13612==    by 0x727BCF: output_in_order(bool) (cgraphunit.c:2011)
>>
>> Following patch just replaces XNEWVAR with XCNEWVAR and it solves all these errors.
>> Ready for trunk?
>
> No.  sparseset is intentionally uninitialized. If you build with valgrind
> checking, sparseset is properly instrumented so that valgrind doesn't
> complain, otherwise just ignore those.
>
> 	Jakub
>

Thank you Jakub for reply, bergner explained me already situation.
Valgrind checking is new for me ;)

Martin
diff mbox

Patch

From ba3abc54772141011b1f8737201a3046031c0e42 Mon Sep 17 00:00:00 2001
From: mliska <mliska@suse.cz>
Date: Fri, 5 Dec 2014 13:23:30 +0100
Subject: [PATCH] sparseset: condition decision based on uninitialized memory.

gcc/ChangeLog:

2014-12-05  Martin Liska  <mliska@suse.cz>

	* sparseset.c (sparseset_alloc): XNEWVAR is replaced with XCNEWVAR.
---
 gcc/sparseset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/sparseset.c b/gcc/sparseset.c
index 628a6e2..f5e5e38b 100644
--- a/gcc/sparseset.c
+++ b/gcc/sparseset.c
@@ -30,7 +30,7 @@  sparseset_alloc (SPARSESET_ELT_TYPE n_elms)
   unsigned int n_bytes = sizeof (struct sparseset_def)
 			 + ((n_elms - 1) * 2 * sizeof (SPARSESET_ELT_TYPE));
 
-  sparseset set = XNEWVAR (struct sparseset_def, n_bytes);
+  sparseset set = XCNEWVAR (struct sparseset_def, n_bytes);
 
   /* Mark the sparseset as defined to silence some valgrind uninitialized
      read errors when accessing set->sparse[n] when "n" is not, and never has
-- 
2.1.2