[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.