Message ID | 1407604073-7484-1-git-send-email-geert@linux-m68k.org |
---|---|
State | Accepted |
Commit | bd8898db3e03147d9d7ddd48876fb3f3bcbab6c1 |
Headers | show |
On Sat, Aug 09, 2014 at 07:07:53PM +0200, Geert Uytterhoeven wrote: > drivers/mtd/nand/nand_timings.c:45: warning: integer constant is too large for ‘long’ type On what compiler / static analyzer? > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > --- > drivers/mtd/nand/nand_timings.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c > index 8b36253420fa..e81470a8ac67 100644 > --- a/drivers/mtd/nand/nand_timings.c > +++ b/drivers/mtd/nand/nand_timings.c > @@ -42,7 +42,7 @@ static const struct nand_sdr_timings onfi_sdr_timings[] = { > .tRHZ_max = 200000, > .tRLOH_min = 0, > .tRP_min = 50000, > - .tRST_max = 250000000000, > + .tRST_max = 250000000000ULL, See [1] and [2]. I'm pretty sure it is a bug in your tool to warn about this. The C standard seems pretty clear that the large literal constant is automatically promoted to a sufficiently large type, so AIUI there should be no need for such a warning. A standards-compliant compiler will do the right thing. It really seems like this type of warning is only appropriate where a smaller literal constant is immediately operated on such that it will overflow. e.g.: .tRST_max = 250 * 1000 * 1000 * 1000, But this usually results in a different type of (correct) warning, like: warning: integer overflow in expression [-Woverflow] However, I could be convinced to apply this, if only to satisfy broken tools and to avoid addressing this question over and over... > .tWB_max = 200000, > .tRR_min = 40000, > .tWC_min = 100000, Brian [1] http://lists.infradead.org/pipermail/linux-mtd/2014-July/054750.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/252494.html
Hi Brian, On Mon, Aug 11, 2014 at 7:50 PM, Brian Norris <computersforpeace@gmail.com> wrote: > On Sat, Aug 09, 2014 at 07:07:53PM +0200, Geert Uytterhoeven wrote: >> drivers/mtd/nand/nand_timings.c:45: warning: integer constant is too large for ‘long’ type > > On what compiler / static analyzer? Any 32-bit version of gcc at the standard warning level, at least until gcc 4.4.7. With gcc 4.6 it's indeed gone. >> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> >> --- >> drivers/mtd/nand/nand_timings.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c >> index 8b36253420fa..e81470a8ac67 100644 >> --- a/drivers/mtd/nand/nand_timings.c >> +++ b/drivers/mtd/nand/nand_timings.c >> @@ -42,7 +42,7 @@ static const struct nand_sdr_timings onfi_sdr_timings[] = { >> .tRHZ_max = 200000, >> .tRLOH_min = 0, >> .tRP_min = 50000, >> - .tRST_max = 250000000000, >> + .tRST_max = 250000000000ULL, > > See [1] and [2]. I'm pretty sure it is a bug in your tool to warn about Yes, I saw those, after I had created my patch. I decided to send it anyway ;-) > this. The C standard seems pretty clear that the large literal constant > is automatically promoted to a sufficiently large type, so AIUI there > should be no need for such a warning. A standards-compliant compiler > will do the right thing. Actually I didn't know there existed versions of gcc that did _not_ give this warning. This seems to be a recent thing on gcc for 32-bit targets. For 64-bit targets, apparently it only gives a warning if the constant is that large that it can no longer fit in a 64-bit signed integer. > However, I could be convinced to apply this, if only to satisfy broken > tools and to avoid addressing this question over and over... So please apply. Too many people are still using 32-bit targets and gcc < 4.6. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, Aug 11, 2014 at 08:51:51PM +0200, Geert Uytterhoeven wrote: > On Mon, Aug 11, 2014 at 7:50 PM, Brian Norris > <computersforpeace@gmail.com> wrote: > > On Sat, Aug 09, 2014 at 07:07:53PM +0200, Geert Uytterhoeven wrote: > >> drivers/mtd/nand/nand_timings.c:45: warning: integer constant is too large for ‘long’ type > > > > On what compiler / static analyzer? > > Any 32-bit version of gcc at the standard warning level, at least > until gcc 4.4.7. > With gcc 4.6 it's indeed gone. > > >> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > >> --- > >> drivers/mtd/nand/nand_timings.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c > >> index 8b36253420fa..e81470a8ac67 100644 > >> --- a/drivers/mtd/nand/nand_timings.c > >> +++ b/drivers/mtd/nand/nand_timings.c > >> @@ -42,7 +42,7 @@ static const struct nand_sdr_timings onfi_sdr_timings[] = { > >> .tRHZ_max = 200000, > >> .tRLOH_min = 0, > >> .tRP_min = 50000, > >> - .tRST_max = 250000000000, > >> + .tRST_max = 250000000000ULL, > > > > See [1] and [2]. I'm pretty sure it is a bug in your tool to warn about > > Yes, I saw those, after I had created my patch. I decided to send it anyway ;-) > > > this. The C standard seems pretty clear that the large literal constant > > is automatically promoted to a sufficiently large type, so AIUI there > > should be no need for such a warning. A standards-compliant compiler > > will do the right thing. > > Actually I didn't know there existed versions of gcc that did _not_ give > this warning. This seems to be a recent thing on gcc for 32-bit targets. > For 64-bit targets, apparently it only gives a warning if the constant > is that large that it can no longer fit in a 64-bit signed integer. I'm curious: do your broken compilers also generate broken code/data? i.e., does gcc 4.4.7 give 250000000000 its proper ULL value still? > > However, I could be convinced to apply this, if only to satisfy broken > > tools and to avoid addressing this question over and over... > > So please apply. Too many people are still using 32-bit targets and > gcc < 4.6. OK, you've convinced me ;) Applied to l2-mtd.git/next, with an editorial comment. Brian
Hi Brian, On Mon, Aug 11, 2014 at 9:06 PM, Brian Norris <computersforpeace@gmail.com> wrote: > I'm curious: do your broken compilers also generate broken code/data? > i.e., does gcc 4.4.7 give 250000000000 its proper ULL value still? Yes it does (checked the assembler output). >> > However, I could be convinced to apply this, if only to satisfy broken >> > tools and to avoid addressing this question over and over... >> >> So please apply. Too many people are still using 32-bit targets and >> gcc < 4.6. > > OK, you've convinced me ;) Applied to l2-mtd.git/next, with an editorial > comment. Thanks! BTW, I had some faint memories of integer constants never being 64-bit without the "LL" suffix, but that's no longer true in c99 (I did check that a few days ago). The warning does go away when adding -std=c99 with gcc-4.4. Interestingly, it doesn't appear with -std=c89 with gcc 4.6.2 or 4.8.2. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c index 8b36253420fa..e81470a8ac67 100644 --- a/drivers/mtd/nand/nand_timings.c +++ b/drivers/mtd/nand/nand_timings.c @@ -42,7 +42,7 @@ static const struct nand_sdr_timings onfi_sdr_timings[] = { .tRHZ_max = 200000, .tRLOH_min = 0, .tRP_min = 50000, - .tRST_max = 250000000000, + .tRST_max = 250000000000ULL, .tWB_max = 200000, .tRR_min = 40000, .tWC_min = 100000,
drivers/mtd/nand/nand_timings.c:45: warning: integer constant is too large for ‘long’ type Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> --- drivers/mtd/nand/nand_timings.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)