GCC 13.2 warns about -Wmaybe-uninitialized when compiling with -Ofast

[sylt]

First of all, this is not reproducible on the develop branch as of writing this.

How to reproduce (on the current master):

$ git clone https://github.com/eyalroz/printf.git
$ cd printf/
$ gcc -c -o /dev/null -Wall -Isrc src/printf/printf.c -Ofast

Yielding the output:

In function ‘apply_scaling’,
    inlined from ‘get_normalized_components’ at src/printf/printf.c:706:29,
    inlined from ‘print_exponential_number’ at src/printf/printf.c:964:5:
src/printf/printf.c:658:66: warning: ‘normalization.raw_factor’ may be used uninitialized [-Wmaybe-uninitialized]
  658 |   return normalization.multiply ? num * normalization.raw_factor : num / normalization.raw_factor;
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/printf/printf.c: In function ‘print_exponential_number’:
src/printf/printf.c:904:25: note: ‘normalization.raw_factor’ was declared here
  904 |   struct scaling_factor normalization;
      |                         ^~~~~~~~~~~~~

I've only seen this on GCC 13.2 (no warning on 9, 11, nor 12), compiling for/on x86-64.

If one doesn't need support for the specifiers %[egEG], the easiest way to work around it is to add -DPRINTF_SUPPORT_EXPONENTIAL_SPECIFIERS=0 when compiling.

[eyalroz]

Dupe of #167 I believe, which is resolved on the development branch. So, closing...

[sylt]

@eyalroz Thanks for having a look! Perhaps I'm mistaken though but I don't think it's a dupe: The fix for #167 is, according to git log, already present on master. Therefore, in my reproduction steps (which is based on master), I don't think I should see it if actually was a dupe, or?

[eyalroz]

You are right, actually.

I've run the command-line you've provided. Interestingly, one gets the error with gcc-13 (13.3.0); but with gcc-14 (14.2.0) there is no warning!

Also, I now notice that it's a different line than the one I added the fix for in #167. So, not a dupe, but still already resolved on development.

[sylt]

Hmm, maybe I misunderstood the bug process, I thought that bugs fixed on development (but are valid on master) were kept open, but with the added label "resolved-on-develop" ?

[eyalroz]

Well, you didn't misunderstand, but since it's a compiler bug, I don't think it makes sense to keep this open. But I'm kind of wishy-washy, so let's say it's open-and-resolved-on-dev