https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175
--- Comment #5 from Arnd Bergmann <arnd at linaro dot org> --- Improving the optimizer will definitely help this one, but not the other instances I found. Here's a list of the remaining warnings that got introduced in the linux kernel by r257857 for reference: https://elixir.bootlin.com/linux/v4.16/source/drivers/acpi/acpi_processor.c#L330 invalid_logical_cpuid() has checked the 'id' variable to be a positive number (i.e. not an error value), so it's assumed to be in the range of [0, 2147483647] by the compiler, while we know it it's in the range of [0, CONFIG_NR_CPUS] when the id is positive. I'd work around that by adding a '< CONFIG_NR_CPUS' check in invalid_logical_cpuid. https://elixir.bootlin.com/linux/v4.16/source/drivers/gpu/drm/imx/imx-ldb.c#L634 The one referenced reported here, ideally handled better by gcc https://elixir.bootlin.com/linux/v4.16/source/drivers/usb/gadget/function/rndis.c#L900 We check the 'id' for a positive number, negative values are error codes. rndis_get_nr() otherwise returns the first available number, so we can assume it's a low number (you won't have billions of USB network interfaces), but making the buffer larger is a safer fix. https://elixir.bootlin.com/linux/v4.16/source/drivers/usb/gadget/udc/fsl_udc_core.c#L2497 We know that max_ep is a small number, but gcc cannot know this, so the loop index has a lower bound but no upper bound. Would work around this by increasing the buffer size from 14 to 16 bytes. https://elixir.bootlin.com/linux/v4.16/source/sound/pci/cmipci.c#L3157 We check for an upper bound but not a lower bound on a signed integer that we know contains a positive number. The warning seems reasonable here, and I would make the variable unsigned. https://elixir.bootlin.com/linux/v4.16/source/drivers/scsi/ch.c#L937 ch->minor is known to be less than 128 CH_MAX_DEVS here, but gcc cannot see this. Again, idr_alloc() returns a negative code in case of an error, so gcc sees that the variable has a lower bound, but not the upper bound. Would work around this using a %hhi modifier. https://elixir.bootlin.com/linux/v4.16/source/drivers/power/supply/sbs-battery.c#L559 sbs_read_word_data() returns either a negative error code or a positive 16-bit number. Would work around that using the %hx modifier. https://elixir.bootlin.com/linux/v4.16/source/net/bluetooth/hci_core.c#L3093 idr_alloc() once more returns a negative number on error, or a positive number that may have an upper bound (the third argument to idr_alloc). Here we should specify the upper bound (10000), but gcc won't see it and still warn, so we also need a way to tell it that 'id' is a four-digit number. Using the %hi format won't work as that is still five digits. To summarize: For this particular project (linux kernel), these added tend to be slightly annoying false-positives, but we can work around that with a handful of simple patches. In five of the eight cases, gcc sees a limited range of [0, 2147483647] because of an explicit check for an error code. I don't know how common that code pattern is in other projects, but for us it would be more logical to treat this like the unbounded range in -Wformat-overflow=2 rather than a range with a known bound for -Wformat-overflow=1.
