grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this


From: PGNet Dev
Subject: Re: fs/ntfscomp.c:82:11: error: ‘flg’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Date: Thu, 26 Mar 2020 04:10:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 3/26/20 1:39 AM, Paul Menzel wrote:

> I am unable to reproduce this with

1st sanity re-check:



I _am_ able to reproduce this consistently, with same error.



I've tested now on multiple machines; not identical, but all similarly opensuse 
+ GCC10 dev envs ... 




> Here is the code in question:

snip

> Why is it complaining complaining in line 82 and not 78, where `flg` is 
> already accessed?

On 3/26/20 3:39 AM, Michael Chang wrote:
> Looking into build log, the build option seems to have been overridden
> with CFLAGS settings like this.
> 
> CFLAGS="-O3 -Wall -fstack-protector-strong -funwind-tables
> -fasynchronous-unwind-tables -fmessage-length=0 -grecord-gcc-switches
> -march=native -mtune=native"
> 
> I'm not sure if -O3 is considered as supported  since that will result
> in larger binaries we are striving to reduce all the time. Also the
> optimization it brings would require careful review if we don't enable
> it by default.
> 
> In addition, -fstack-protector-strong breaks the build even harder with
> a lot of __stack_chk_fail undefined symbol in the modules.
> 
> If going with default build option, I also don't have this compliation
> error.


indeed.

building with

        unset CC CPP
+       unset LD CFLAGS CPPFLAGS CXXFLAGS

        ./bootstrap
        ./autogen.sh

        ./configure \
        --prefix=/usr/local/grub-build-test

        make V=1

completes without error, and installs,


        /usr/local/grub-build-test/bin/grub-mkrescue --version
                /usr/local/grub-build-test/bin/grub-mkrescue (GRUB) 2.05


which I can certainly manage easily enough for local build.

> If going with default build option

_is_ a 'clear' env expected/recommended/required for a grub2 build?  if so, 
does this need to be handled at config time?

in either case, this

> Why is it complaining complaining in line 82 and not 78, where `flg` is 
> already accessed?


doesn't make sense to me; code looks straightforward enough.  the -03 
optimization sounds a good 1st guess.

also,
Michael, fyi, I _think_ this^ started for me with linked GCC10 builds of grub2 
on opensuse OBS ... where, iirc, the builds 1st failed, and I started testing 
locally.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]