On 08/09/16 16:31, Dave Gordon wrote: > On 08/09/16 00:02, Nicolas Iooss wrote: >> On 07/09/16 18:03, Dave Gordon wrote: >>> On 06/09/16 21:36, Nicolas Iooss wrote: >>>> On 06/09/16 12:21, Dave Gordon wrote: >>>>> On 04/09/16 19:58, Nicolas Iooss wrote: >>>>>> When building the kernel with clang and some warning flags, the >>>>>> compiler >>>>>> reports that the return value of dcs_get_backlight() may be >>>>>> uninitialized: >>>>>> >>>>>> drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: >>>>>> variable >>>>>> 'data' is used uninitialized whenever 'for' loop exits because >>>>>> its >>>>>> condition is false [-Werror,-Wsometimes-uninitialized] >>>>>> for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) { >>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> drivers/gpu/drm/i915/intel_dsi.h:126:49: note: expanded from >>>>>> macro >>>>>> 'for_each_dsi_port' >>>>>> #define for_each_dsi_port(__port, __ports_mask) >>>>>> for_each_port_masked(__port, >>>>>> __ports_mask) >>>>>> >>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> drivers/gpu/drm/i915/i915_drv.h:322:26: note: expanded from macro >>>>>> 'for_each_port_masked' >>>>>> for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; >>>>>> (__port)++) \ >>>>>> ^~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:60:9: note: >>>>>> uninitialized use occurs here >>>>>> return data; >>>>>> ^~~~ >>>>>> >>>>>> As intel_dsi->dcs_backlight_ports seems to be always initialized to a >>>>>> non-null value, the content of the for loop is always executed and >>>>>> there >>>>>> is no bug in the current code. Nevertheless the compiler has no >>>>>> way of >>>>>> knowing that assumption, so initialize variable 'data' to silence the >>>>>> warning here. >>>>>> >>>>>> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@xxxxxxx> >>>>> >>>>> Interesting ... there are two things that could lead to this >>>>> (possibly) >>>>> incorrect analysis. Either it thinks the loop could be executed zero >>>>> times, which would be a deficiency in the compiler, as the initialiser >>>>> and loop bound are both known (different) constants: >>>>> >>>>> enum port { >>>>> PORT_A = 0, >>>>> PORT_B, >>>>> PORT_C, >>>>> PORT_D, >>>>> PORT_E, >>>>> I915_MAX_PORTS >>>>> }; >>>>> >>>>> or, it doesn't understand that because we've passed &data to another >>>>> function, it can have been set by the callee. It may be extra >>>>> confusing >>>>> that the callee takes (void *); or it may be being ultra-sophisticated >>>>> in its analysis and noted that in one error path data is *not* set >>>>> (and >>>>> we then discard the error and use data anyway). As an experiment, you >>>>> could try: >>>> >>>> The code that the compiler sees is not a simple loop other enum 'port' >>>> but "for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {", which >>>> is expanded [1] to: >>>> >>>> for ((port) = PORT_A; (port) < I915_MAX_PORTS; (port)++) >>>> if (!((intel_dsi->dcs_backlight_ports) & (1 << (port)))) {} >>>> else { >>>> >>>> This is why I spoke of intel_dsi->dcs_backlight_ports in my >>>> description: >>>> if it is zero, the body of the loop is never run. >>>> >>>> As for the analyses of calls using &data, clang does not warn about the >>>> variable being maybe uninitialized following a call. This is quite >>>> expected as this would lead to too many false positives, even though it >>>> may miss some bugs. >>>> >>>>> static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 >>>>> cmd) >>>>> { >>>>> u8 data = 0; >>>>> >>>>> mipi_dsi_dcs_read(dsi_device, cmd, &data, sizeof(data)); >>>>> >>>>> return data; >>>>> } >>>>> >>>>> static u32 dcs_get_backlight(struct intel_connector *connector) >>>>> { >>>>> struct intel_encoder *encoder = connector->encoder; >>>>> struct intel_dsi *intel_dsi = >>>>> enc_to_intel_dsi(&encoder->base); >>>>> struct mipi_dsi_device *dsi_device; >>>>> enum port port; >>>>> u8 data; >>>>> >>>>> /* FIXME: Need to take care of 16 bit brightness level */ >>>>> for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) { >>>>> dsi_device = intel_dsi->dsi_hosts[port]->device; >>>>> data = mipi_dsi_dcs_read1(dsi_device, >>>>> MIPI_DCS_GET_DISPLAY_BRIGHTNESS); >>>>> break; >>>>> } >>>>> >>>>> return data; >>>>> } >>>>> >>>>> If it complains about that then it's a shortcoming in the loop >>>>> analysis. >>>> >>>> It complains (in dcs_get_backlight), because for_each_dsi_port() still >>>> hides an 'if' condition. >>> >>> So it does, In that case the complaint is really quite reasonable. >>> >>>>> If not you could try: >>>>> >>>>> static u8 mipi_dsi_dcs_read1(struct mipi_dsi_device *dsi_device, u8 >>>>> cmd) >>>>> { >>>>> u8 data; >>>>> ssize_t nbytes = sizeof(data); >>>>> >>>>> nbytes = mipi_dsi_dcs_read(dsi_device, cmd, &data, nbytes); >>>>> return nbytes == sizeof(data) ? data : 0; >>>>> } >>>>> >>>>> and if complains about that then it doesn't understand that passing >>>>> &data allows it to be set. If it doesn't complain about this version, >>>>> then the original error was actually correct, in the sense that >>>>> data can >>>>> indeed be used uninitialised if certain error paths can be taken. >>>> >>>> clang did not complain with this last case. >>> >>> It probably should have, since the (hidden) if() could still result in >>> this function never being called. Oh well ... >> >> Sorry, my message was not clear enough. The compiler did not complain in >> mipi_dsi_dcs_read1() in the last case, but the -Wsometimes-uninitialized >> warning was still there for variable 'data' in dcs_get_backlight(), as >> expected because of the "hidden if". >> >> Nicolas > > OK, thanks. > > BTW do you see any "may be used uninitialised" warnings in > gen{6,8}_ggtt_insert_entries()? In particular > > for_each_sgt_dma(addr, sgt_iter, st) { > gtt_entry = gen8_pte_encode(addr, level, true); > gen8_set_pte(>t_entries[i++], gtt_entry); > } > > [snip] > > if (i != 0) > WARN_ON(readq(>t_entries[i-1]) != gtt_entry); > > Or maybe clang is smart enough to realise that the WARN_ON() is > reachable only if the gen8_set_pte() has already been executed at least > once? > > .Dave. The clang I am using (version 3.8.1) does not report any -Wsometimes-uninitialized warning in drivers/gpu/drm/i915/i915_gem_gtt.c. Even when I introduce a statement which uses gtt_entry right after the for_each_sgt_dma loop (like printk("%llu", gtt_entry);) no warning is produced. Therefore the lack of the warning does not mean the compiler is finding that i != 0 only when the loop got executed once, I guess the loop condition is too complex for the compiler to decide whether the loop body is always executed. Nicolas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx