From: Mike Beaton
This warning was already disabled in CLANGDWARF by commit
d3225577123767fd09c91201d27e9c91663ae132.
gcc can distinguish between optimised-away variable usage (as can occur in
valid debug code) and genuinely unused variables, and only complains about
the latter. clang cannot, a
Repeats the commit already acked by Ard in
https://edk2.groups.io/g/devel/topic/103083030, though with an attempt
to provide an additional (not yet acked) useful commit message.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112261): http
Resolves https://bugzilla.tianocore.org/show_bug.cgi?id=4620
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112262): https://edk2.groups.io/g/devel/message/112262
Mute This Topic: https://groups.io/mt/103087794/21656
Group Owner: devel+ow
On 12/10/23 11:18, Mike Beaton wrote:
> From: Mike Beaton
>
> This warning was already disabled in CLANGDWARF by commit
> d3225577123767fd09c91201d27e9c91663ae132.
>
> gcc can distinguish between optimised-away variable usage (as can occur in
> valid debug code) and genuinely unused variables,
I believe this would be logically wrong, as the other versions still
wouldn't compile if you changed the relevant debug Pcds. (Which are
logically independent of the compile and link options - e.g. what if for
some reason you wanted to single step with the Debug Pcds set to disabled,
in a NOOPT bui
On 12/11/23 16:18, Mike Beaton wrote:
> I believe this would be logically wrong, as the other versions still
> wouldn't compile if you changed the relevant debug Pcds. (Which are
> logically independent of the compile and link options - e.g. what if for
> some reason you wanted to single step with
> > I believe this would be logically wrong, as the other versions still
> > wouldn't compile if you changed the relevant debug Pcds. (Which are
> > logically independent of the compile and link options - e.g. what if for
> > some reason you wanted to single step with the Debug Pcds set to
> > disa
On 12/11/23 18:26, Mike Beaton wrote:
>>> I believe this would be logically wrong, as the other versions still
>>> wouldn't compile if you changed the relevant debug Pcds. (Which are
>>> logically independent of the compile and link options - e.g. what if for
>>> some reason you wanted to single st
> > A completely different approach, which allows clang to spot that the
> > usage has been 'optimised away' and so to not complain (and therefore
> > allows us to re-enable the warning in CLANGDWARF as well), is the
> > following:
> >
> > --- a/MdePkg/Include/Library/DebugLib.h
> > +++ b/MdePkg/In
On Tue, 12 Dec 2023 at 08:17, Mike Beaton wrote:
>
> > > A completely different approach, which allows clang to spot that the
> > > usage has been 'optimised away' and so to not complain (and therefore
> > > allows us to re-enable the warning in CLANGDWARF as well), is the
> > > following:
> > >
>
I have realised that this was already fixed (i.e. allowing keeping the
warning) in Acidanthera fork of EDK-II. Discussed here
https://bugzilla.tianocore.org/show_bug.cgi?id=3704 - includes the fix
in question and other fixes for newer gcc as well. I'll post a new
patch to the list proposing just th
> I have realised that this was already fixed (i.e. allowing keeping the
> warning) in Acidanthera fork of EDK-II. Discussed here
> https://bugzilla.tianocore.org/show_bug.cgi?id=3704 - includes the fix
> in question and other fixes for newer gcc as well. I'll post a new
> patch to the list proposi
> I'm running some further tests to confirm that the simple version
> proposed above builds in all the Acidanthera test environments, which
> is relevant in that it should rule out at least any obvious problems
> with it building in all edk-2 environments, too. (I had already run
> quick tests for
13 matches
Mail list logo