> So, to summarize, I think this is the complete set of viable
> alternatives:
>
> 1. Status quo. Nothing changes.
>
> 2. Run the maybe uninitialized warning code earlier in the pipeline
> with no other changes. Will result in more false positives, but
> more consistent results.
>
> 3. Allow a user switch to determine if the maybe uninitialized code
> runs early in the pipeline (more false positives, but more
> consistent results), or late in the pipeline (fewer false
> positives, but results fluctuate as optimizers change).
>
> 3a. Switch on with -Wuninitialized
> 3b. Switch off with -Wuninitialized
>
> 4. Use an approach which runs both late and early which allows us
> to explicitly warn about cases where a maybe-uninitialized
> variable
> was either eliminated or proven always initialized. A switch
> controls the new warning.
>
> 4a. Switch defaults to on with -Wuninitialized
> 4b. Switch defaults to off with -Wuninitialized.
>
> My favorites (in preferred order) would be 3b, 4b, and 4a.
> 3a and 1 are less appealing with 2 being the worst choice IMHO.
> Other thoughts, opinions and comments are encouaged :-)
> jeff
I prefer consistency in warnings, regardless of optimization level.
We already say warning flags should not affect codegen and therefore
optimizations performed. IMHO the reverse should also hold,
optimization level should not affect warnings generated.
False positives for -Wuninitialized are easily corrected by
initializing at declaration. But lacking consistency can be annoying
when a newly detected stray false positive kills -Werror compilations
for infrequently tested configuration options, not because the code
changed but because different optimizations were performed. Think
oddball configs in gcc bootstraps, or the occasional -O3 bootstraps on
any config yielding a new false positive. Leaving aside cpp
conditional code paths, I want to know the universe (or as close as I
can) of possible false positives with my one and only common bootstrap
and fix them all right away, and be done with warning repairs.
If the initialization is redundant, it won't matter to codegen.
I.e. if the optimizer is smart enough to eliminate the uninitialized
path, then IMHO it should be smart enough (is already smart enough?)
to eliminate the dead store at the declaration. Thus there shouldn't
be any pessimization penalty for silencing the warning. In fact I'll
go as far as saying I don't think 4 is ever a useful warning,
especially from a -Werror perspective.
So if I understand #3 correctly where early==on and late==off for the
new flag, then my preferred order is 3a, 2.
I think 3b or 4a yield inherently inconsistent results by definition
and are therefore to be avoided.
I'm not sure what 4b means. When this early&late switch is off does
-Wuninitialized degenerate to 2 (early-only) or 3b (late-only) in your
mind? If 2 then IMHO it's not horrible but not useful, if 3b then I
don't like it.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
