Gcc -Wuninitialized/-Wmaybe-Uninitialized Issues

GCC 5 error, maybe used uninitialized

Found answer,
Line # 683
Edited by adding

int *uv = 0, *ua = 0;

Here is full code

    static int
clock_krait_8974_driver_probe(struct platform_device *pdev)
    {
    struct device *dev = &pdev->dev;
    struct clk *c;
    int speed, pvs, pvs_ver, config_ver, rows, cpu;
    unsigned long *freq, cur_rate, aux_rate;
    int *uv = 0, *ua = 0;
    u32 *dscr = NULL, vco_mask, config_val;
    int ret;

    vdd_l2.regulator[0] = devm_regulator_get(dev, "l2-dig");
    if (IS_ERR(vdd_l2.regulator[0])) {
        dev_err(dev, "Unable to get l2-dig regulator!\n");
        return PTR_ERR(vdd_l2.regulator[0]);
    }

GCC not complaining about uninitialized variable

An optimiser can figure out that the whole loop is pointless, but it is a bit complicated. The loop is pointless because the values of i and j are not used after the loop, and j is used inside the loop only to decide when to break early, which doesn't matter either because the number of iterations of the loop doesn't matter. So in this situation, if you initialised j to a random number, you would get exactly the same result. So the compiler may not issue a warning because nothing harmful will happen.

Obviously you have undefined behaviour, so the whole app could just crash because of the uninitialised variable. But that is up to the compiler, so if that happened, you should get a warning.

gcc compiler ignores uninitialized variable warning for debug build

Though it may look weird, this behavior is documented for -Wmaybe-uninitialized gcc option:

-Wmaybe-uninitialized

For an automatic (i.e. local) variable, if there exists a path from the function entry to a use of the variable that is initialized, but there exist some other paths for which the variable is not initialized, the compiler emits a warning if it cannot prove the uninitialized paths are not executed at run time.

These warnings are only possible in optimizing compilation, because otherwise GCC does not keep track of the state of variables.

I guess the reason is that the cost of analyzing not initialized variables is too much for not optimizing compilation. That's why it is done only for optimizing one.

Uninitialized warning with GCC optimizer

I think the warning is a bug. Which gcc are you using? Doesn't happen for me when I compile (admittedly a single file) with gcc 4.0 and 4.2.

Here is an annotated version of the optimised assembler. I can't see anything unassigned here, which is why I think the warning is not right. I've guessed about the tree structure.

tsiterator:
    pushl   %ebp
    movl    %esp, %ebp
    movl    12(%ebp), %edx  ; edx has pointer to ts
    pushl   %ebx
    movl    8(%ebp), %eax   ; eax has pointer to retval
    movl    (%edx), %ecx    ; ecx has ts->tree (?)
    movl    4(%ecx), %edx   ; edx has ts->tree->min (?)
    movl    %ecx, 4(%eax)   ; store ts->tree into retval->iter->tree
    cmpl    $1, %edx    
    movl    %edx, (%eax)    ; store ts->tree->min into retval->iter->current
    ;; This and the cmpl instruction above is all
    ;; handling the bitmasking for retval->iter->info.
    ;; Probably would be more efficient to not use a
    ;; bit mask here, as the compiler could remove the
    ;; second "and" and "or" instructions.
    movzbl  8(%eax), %edx   ; get current value of retval->iter->info
    sbbl    %ebx, %ebx  ; ebx = 0 if unsigned edx < 1, else -1
    andl    $3, %ebx    ; mask off new value            
    andl    $-4, %edx   ; mask off old value   
    orl     %ebx, %edx  ; combine old | new    
    movb    %dl, 8(%eax)    ; store combined into retval->iter->info
    popl    %ebx
    popl    %ebp
    ret $4

EDIT: Note that the compiler carefully preserves the upper 6 bits of random uninitialized junk in tree_iter_t.info.

---

Related Topics