As far as I can tell, the warnings are all false positives, and GCC is
normally able to prove that (in lot of cases, it's not obvious that
the variable is assigned in all runs).

My hypothesis is that -O0 turns off the initialization check
completely to save time, -O1 turns on very basic checking, and -O2 and
above use a much more sophisticated (and expensive) algorithm to prune
results from the basic check. Whether it's intended or not, I couldn't
say, but I suspect one of the -Wwarning-name options could,
counterintuitively, silence the warnings.

On 20 October 2017 at 01:49, Ondřej Hlavatý <[email protected]> wrote:
> There are few of them, but this one is OK. The value is always
> initialized, and apparantly GCC is able to prove it sometimes.
>
> Actually, most of the warnings I get with -Og are false alarms. Only
> very few of them are real. That's why I think we should rather
> explicitly turn on the magic yet unknown option, than to specify
> unnecessary default values to silence GCC. Or a least make
> maybe-uninitialized onlu a warning.
>
> What's even more strange, now I cannot reproduce it with -O3 neither.
> But I'm pretty sure it was -O3. Also, I wasn't the first to notice this
> behavior, Petr Mánek did (CCing him). Maybe he can add some details from
> his side.
>
> $ amd64-unknown-elf-gcc -v
> Using built-in specs.
> COLLECT_GCC=bin/amd64-unknown-elf-gcc
> COLLECT_LTO_WRAPPER=/home/ohlavaty/.local/cross/amd64-unknown-elf/bin/../libexec/gcc/amd64-unknown-elf/7.1.0/lto-wrapper
> Target: amd64-unknown-elf
> Configured with: 
> /home/ohlavaty/projects/helenos/xhci/amd64-unknown-elf/gcc-7.1.0/configure 
> --target=amd64-unknown-elf 
> --prefix=/home/ohlavaty/.local/cross//amd64-unknown-elf 
> --program-prefix=amd64-unknown-elf- --with-gnu-as --with-gnu-ld --disable-nls 
> --disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib 
> --disable-libgcj --without-headers --disable-shared --enable-lto 
> --disable-werror
> Thread model: single
> gcc version 7.1.0 (GCC)
>
> OH
>
> On 20.10., Jiří Zárevúcky wrote:
>> The weirdest part that as far as I can tell, those are legit bugs.
>>
>> On my end, I get no warnings whatsoever. The whole build is clean.
>>
>> On 20 October 2017 at 01:17, Ondřej Hlavatý <[email protected]> wrote:
>> > OK, this one is just too weird. It seems GCC turns off some heuristics.
>> > It might be a better option to find out how to turn it back on on lower
>> > optimization levels.
>> >
>> > See this (command taken from make output, optimization moved to the very
>> > end):
>> >
>> > $ cd uspace/drv/bus/pci/pciintel
>> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
>> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
>> > -I../../../../../abi/include -imacros ../../../../../config.h 
>> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
>> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
>> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
>> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
>> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
>> > -I../../../../lib/drv/include -c pci.c -o pci.o -O0
>> >
>> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
>> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
>> > -I../../../../../abi/include -imacros ../../../../../config.h 
>> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
>> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
>> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
>> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
>> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
>> > -I../../../../lib/drv/include -c pci.c -o pci.o -O1
>> >
>> > pci.c: In function 'pci_conf_write':
>> > pci.c:322:7: error: 'val' may be used uninitialized in this function 
>> > [-Werror=maybe-uninitialized]
>> >    val &= ~(0xffU << ((reg & 3) * 8));
>> >    ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > cc1: all warnings being treated as errors
>> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
>> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
>> > -I../../../../../abi/include -imacros ../../../../../config.h 
>> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
>> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
>> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
>> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
>> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
>> > -I../../../../lib/drv/include -c pci.c -o pci.o -O2
>> >
>> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
>> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
>> > -I../../../../../abi/include -imacros ../../../../../config.h 
>> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
>> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
>> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
>> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
>> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
>> > -I../../../../lib/drv/include -c pci.c -o pci.o -O3
>> >
>> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
>> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
>> > -I../../../../../abi/include -imacros ../../../../../config.h 
>> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
>> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
>> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
>> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
>> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
>> > -I../../../../lib/drv/include -c pci.c -o pci.o -Ofast
>> >
>> > $ $CROSS_PREFIX/amd64-unknown-elf/bin/amd64-unknown-elf-gcc  
>> > -I../../../../lib/c/include -I../../../../lib/c/arch/amd64/include 
>> > -I../../../../../abi/include -imacros ../../../../../config.h 
>> > -ffreestanding -fno-builtin -nostdlib -nostdinc -fexec-charset=UTF-8 
>> > -finput-charset=UTF-8 -D__LE__ -Werror -fno-omit-frame-pointer 
>> > -ffunction-sections -Wall -Wextra -Wno-clobbered -Wno-unused-parameter 
>> > -Wmissing-prototypes -std=gnu99 -Werror-implicit-function-declaration 
>> > -Wwrite-strings -pipe -mno-tls-direct-seg-refs -g 
>> > -I../../../../lib/drv/include -c pci.c -o pci.o -Og
>> >
>> > pci.c: In function 'pci_conf_write':
>> > pci.c:322:7: error: 'val' may be used uninitialized in this function 
>> > [-Werror=maybe-uninitialized]
>> >    val &= ~(0xffU << ((reg & 3) * 8));
>> >
>> > How does this behave on your end?
>> >
>> > OH
>> >
>> > On 20.10., Jiří Zárevúcky wrote:
>> >> Weird!
>> >>
>> >> Whatever the reason for suspicious silence here, this needs to be fixed.
>> >> It would be great if you could fix all the warnings you are getting.
>> >> I'll merge your directive as soon as you have it.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> On 20 October 2017 at 00:20, Ondřej Hlavatý <[email protected]> wrote:
>> >> > Hi,
>> >> >
>> >> > On 19.10., Jiří Zárevúcky wrote:
>> >> >> Could you elaborate on your setup?
>> >> >> In particular, do you use the proper cross-compiler, as built using
>> >> >> toolchain.sh?
>> >> >
>> >> > I just installed fresh toolchain, distclean, loaded amd64 defaults and
>> >> > it happened. Strangely, no warnings are reported with -O2.
>> >> >
>> >> >> Also, did you add any additional compiler flags?
>> >> >
>> >> > No.
>> >> >
>> >> >> Any other changes? Differences from default settings?
>> >> >
>> >> > My CROSS_PREFIX is set to dir in my home, not the system default. It
>> >> > still contains the old toolchain, if that could matter.
>> >> >
>> >> > I can't think of any other difference - I don't even use the mainline
>> >> > checkout while working on xhci.
>> >> >
>> >> > OH
>> >> >
>> >> >> On 19 October 2017 at 23:40, Ondřej Hlavatý <[email protected]> wrote:
>> >> >> > Well, it seems that the patch is sufficient only when compiling with
>> >> >> > -O3. There are a lot of other warnings with -Og. It is probably worth
>> >> >> > checking them all (possibly with -O0) and fixing/muting them at once.
>> >> >> >
>> >> >> > Shall I prepare that?
>> >> >> >
>> >> >> > OH
>> >> >> >
>> >> >> > On 19.10., Ondra Hlavatý wrote:
>> >> >> >> Hi all,
>> >> >> >>
>> >> >> >> When building current mainline with freshly downloaded toolchain, 
>> >> >> >> GCC
>> >> >> >> 7.1.0 complains about uninitialized variables. First of them is real
>> >> >> >> (extent.c), the second is not, but it's probably too hard for GCC to
>> >> >> >> infer.
>> >> >> >>
>> >> >> >> Hope you're enjoing the hangout.
>> >> >> >> Ondra Hlavatý
>> >> >> >
>> >> >> >> # Bazaar merge directive format 2 (Bazaar 0.90)
>> >> >> >> # revision_id: [email protected]
>> >> >> >> # target_branch: bzr://bzr.helenos.org/mainline/
>> >> >> >> # testament_sha1: 5343d00f1a73b4b8864f22d5e19dae0f155642cd
>> >> >> >> # timestamp: 2017-10-19 22:32:34 +0200
>> >> >> >> # base_revision_id: [email protected]\
>> >> >> >> #   ndrkufle1quqodg8
>> >> >> >> #
>> >> >> >> # Begin patch
>> >> >> >> === modified file 'uspace/lib/ext4/src/extent.c'
>> >> >> >> --- uspace/lib/ext4/src/extent.c      2017-05-11 22:07:09 +0000
>> >> >> >> +++ uspace/lib/ext4/src/extent.c      2017-10-19 20:30:01 +0000
>> >> >> >> @@ -374,7 +374,7 @@
>> >> >> >>  int ext4_extent_find_block(ext4_inode_ref_t *inode_ref, uint32_t 
>> >> >> >> iblock,
>> >> >> >>      uint32_t *fblock)
>> >> >> >>  {
>> >> >> >> -     int rc;
>> >> >> >> +     int rc = EOK;
>> >> >> >>       /* Compute bound defined by i-node size */
>> >> >> >>       uint64_t inode_size =
>> >> >> >>           ext4_inode_get_size(inode_ref->fs->superblock, 
>> >> >> >> inode_ref->inode);
>> >> >> >>
>> >> >> >> === modified file 'uspace/lib/trackmod/xm.c'
>> >> >> >> --- uspace/lib/trackmod/xm.c  2014-10-13 17:31:01 +0000
>> >> >> >> +++ uspace/lib/trackmod/xm.c  2017-10-19 20:30:01 +0000
>> >> >> >> @@ -288,7 +288,7 @@
>> >> >> >>       size_t samples;
>> >> >> >>       size_t instr_size;
>> >> >> >>       size_t smp_size;
>> >> >> >> -     size_t smp_hdr_size;
>> >> >> >> +     size_t smp_hdr_size = 0; /* GCC false alarm on uninitialized 
>> >> >> >> */
>> >> >> >>       ssize_t nread;
>> >> >> >>       uint8_t ltype;
>> >> >> >>       trackmod_sample_t *sample;
>> >> >> >>
>> >> >> >> # Begin bundle
>> >> >> >> IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWe8h8/IAAhpfrAAwUPf//17I
>> >> >> >> lAC////wACAAAgoAUASu73TT2tb13oim3qnhJQgp4m1T0mnqemTVPyp+o9Sfoo9qn6oMh6jQbRBl
>> >> >> >> GhGJpo0mkPU0A0AAAAABKEBRoyCbRMTT1GjQAAaNGgAaaoCbKNAAGjQaA0AGg0ABJJNGmpgTET0n
>> >> >> >> oENNI8pkaDQGgNGE5ypN3TW0+0R5HZU5WV9U0/YwFtIdsdkMEzXS50UmZKCSSkkO9B2beBJRTDBB
>> >> >> >> fETXzctT0PJvAt9bQk9U2VMYCzRs2vIqiyYKGc07734syjxSqw1mJBlQLfHZxNdkb7RszqhmPmzY
>> >> >> >> L+AbSq+tfe9BqrcUtO2E5Qwx5KxA6RX9ae6s2j4UjvnbmBv+Os3l0ewCIY0HDDAwyEwkwiQgTGkd
>> >> >> >> KppsRtJPGLIgqLCIPGf4Hd+wIEgyM41hteE6Rc3XdQUl7SltqQ4ZMpgvzIFuLoRaG/aXCyu7yFNq
>> >> >> >> EKwVI2HxRJwt7cSbcSIBfIUyLiwFZAzLDzWjgByvVSmxSDIDpMtldhLoyjaTq6dDxziYCQpNxcUA
>> >> >> >> UmyadFcQgM8Z7FprqSghIN+hLJSmhwAVsxF1ZCBRZcsz0BszFVp0V3idomXU0lZuwRhYSLg5lRbT
>> >> >> >> W7moCZEk9rTjBzCsXpFIt0BT6MD1DVZbXkFyiBWWCnyI54CE77CwZkiS11pEdNQSZ9rUQi5ixt7i
>> >> >> >> 64JiBZkBTqzC4Jg6TLDgFBZTAPaHSnVODxBYzGXDRyohYsvMQDPpKyV8nSMUH2OMlu5QxVezVOfk
>> >> >> >> esUalyPYFiraTEDjpdSVy1tQiCiFjKLLJQmGMRRoBdQOLBBJOzsPY1PqDbF8jGdJengFEu5nHMKP
>> >> >> >> qMpAM6leHOdcNhXTspYxNSYw+10EcO1dTVZMHrtxMY9/O9LSoU4INE9QQOOGNnFjaK3tget7SInN
>> >> >> >> hFFtpv6sEqdEmXGoi1DjkG8fSdheYa7pWaRVLPn2SIKw5mfxklL99FMvbWEwM8SlnW9XAX9pBdBP
>> >> >> >> CTGrcaJ5HvLTTl3vWgrAqphfE19OB3lZ2GM3Bh1haia+KDOdA/bncX4a37tDPd+kHOz3Qzsq5NMK
>> >> >> >> gYRJgaCNcF2Fd9p/ZALzoRjx8yPWbpRh0YHXcS9vdldGpiZcTeSFqvaSEpYsRWHtWOIErYBVHnLk
>> >> >> >> d50omtMjGwvR7xnjEm9wyrjQiRA7yh1mKrW0TzI8kPquqJX+f63Yw6UYIZBzRHMsvoPiQ8KfhJXo
>> >> >> >> nm4zwkKW2on1O9iYueSgChEjQpNc3OMLUwz8dK4w8C3g57O0DZ4LcruCthUY2ghjK4cZFH9pIacG
>> >> >> >> Q4CUEOVNfQ4ir74wNI0u3hBVDuZZf16C7erepZMURR2SnJFC63Kcz2gZfACtU6mGAWXai4Y9Tr0K
>> >> >> >> F2AcqItgRvWZXPJlttKHEhUeCwpFWVS1yoITAzidBNU/qjVQYOVJFGlA4PZQELCWmQgClk6RXJCP
>> >> >> >> zSKkCwKKItkBRz3m+QeRAzUxglsnxIgeF29VP4LNstLNyukyIpcZCySKtRjByqAgrj3nia6Dnjyb
>> >> >> >> MkajQmgcewDuAbNsVYiePp6YwfxdyRThQkO8h8/I
>> >> >> >
>> >> >> >> _______________________________________________
>> >> >> >> HelenOS-devel mailing list
>> >> >> >> [email protected]
>> >> >> >> http://lists.modry.cz/listinfo/helenos-devel
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > HelenOS-devel mailing list
>> >> >> > [email protected]
>> >> >> > http://lists.modry.cz/listinfo/helenos-devel
>> >> >>
>> >> >> _______________________________________________
>> >> >> HelenOS-devel mailing list
>> >> >> [email protected]
>> >> >> http://lists.modry.cz/listinfo/helenos-devel
>> >> >
>> >> > _______________________________________________
>> >> > HelenOS-devel mailing list
>> >> > [email protected]
>> >> > http://lists.modry.cz/listinfo/helenos-devel
>> >>
>> >> _______________________________________________
>> >> HelenOS-devel mailing list
>> >> [email protected]
>> >> http://lists.modry.cz/listinfo/helenos-devel
>> >
>> > _______________________________________________
>> > HelenOS-devel mailing list
>> > [email protected]
>> > http://lists.modry.cz/listinfo/helenos-devel
>>
>> _______________________________________________
>> HelenOS-devel mailing list
>> [email protected]
>> http://lists.modry.cz/listinfo/helenos-devel
>
> _______________________________________________
> HelenOS-devel mailing list
> [email protected]
> http://lists.modry.cz/listinfo/helenos-devel

_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel

Reply via email to