This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] TRACING: Fix a copmile warning
- From: Steven Rostedt <rostedt at goodmis dot org>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Arnaud Lacombe <lacombar at gmail dot com>, gcc-help at gcc dot gnu dot org, stufever at gmail dot com, linux-kernel at vger dot kernel dot org, Wang Shaoyan <wangshaoyan dot pt at taobao dot com>, Frederic Weisbecker <fweisbec at gmail dot com>, Ingo Molnar <mingo at redhat dot com>
- Date: Mon, 25 Jul 2011 21:10:28 -0400
- Subject: Re: [PATCH] TRACING: Fix a copmile warning
- References: <1310982010-13849-1-git-send-email-wangshaoyan.pt@taobao.com> <1311618747.3526.32.camel@gandalf.stny.rr.com> <CACqU3MVJ9Oj4pXH9O_2jnqDVBqKA+AgoWHwP-n2HGD4LU0pMHQ@mail.gmail.com> <1311625197.3526.35.camel@gandalf.stny.rr.com> <CACqU3MUKU_0FbOQT+TKLnnaoFVS_QOgzzx-tvunQy94v-eykTw@mail.gmail.com> <CACqU3MXO_oR+8Ac2Z7wSji0sUeu-2FwskmxZxtY9NV+XpJXuwA@mail.gmail.com> <mcrfwltoov5.fsf@coign.corp.google.com>
On Mon, 2011-07-25 at 17:41 -0700, Ian Lance Taylor wrote:
> Arnaud Lacombe <lacombar@gmail.com> writes:
> > It seems gcc transforms the conditional from:
> >
> > if (a != NULL && b != NULL) ...
> >
> > to
> >
> > if (b != NULL && a != NULL) ...
> >
> > In which case the warning is fully valid. I'm not sure what's the C
> > standard guarantee in term of conditional test order. gcc 4.7.0 has
> > the same behavior.
>
> Not quite. C guarantees that && is executed in order. In this case gcc
> is generating
>
> a = e();
> if (a != NULL)
> b = f();
> if (a != NULL & b != NULL)
> g();
>
> Note the change from && to & in the last conditional. This
> transformation is safe, in that it does not change the meaning of the
> program. However, it does cause a read of an uninitialized memory
> location, and this is causing a later gcc pass to generate a false
> positive warning.
>
Looking at the assembly again, and not knowing what gcc is doing
internally, it does seem to be:
if (a != NULL)
b = f();
if (b != NULL && a != NULL)
g();
But if the first conditional fails, then the second will never pass
regardless of what b is. In which case, it is the same as:
if (a != NULL)
b = f();
if (a != NULL && b != NULL)
g();
And it doesn't change the meaning of the code.
> Please consider filing a bug report about this false positive. Thanks.
I agree that this is just a warning bug.
On a tangent:
Compiling with -O2 (which gives no warning) (x86_64) produces:
0000000000000000 <fn>:
0: 48 83 ec 08 sub $0x8,%rsp
4: e8 00 00 00 00 callq 9 <fn+0x9>
5: R_X86_64_PC32 e-0x4
9: 48 85 c0 test %rax,%rax
c: 74 1a je 28 <fn+0x28>
e: e8 00 00 00 00 callq 13 <fn+0x13>
f: R_X86_64_PC32 f-0x4
13: 48 85 c0 test %rax,%rax
16: 74 10 je 28 <fn+0x28>
18: 48 83 c4 08 add $0x8,%rsp
1c: e9 00 00 00 00 jmpq 21 <fn+0x21>
1d: R_X86_64_PC32 g-0x4
21: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
28: 48 83 c4 08 add $0x8,%rsp
2c: c3 retq
and compiling with -Os:
0000000000000000 <fn>:
0: 55 push %rbp
1: 53 push %rbx
2: 51 push %rcx
3: e8 00 00 00 00 callq 8 <fn+0x8>
4: R_X86_64_PC32 e-0x4
8: 48 85 c0 test %rax,%rax
b: 48 89 c3 mov %rax,%rbx
e: 74 08 je 18 <fn+0x18>
10: e8 00 00 00 00 callq 15 <fn+0x15>
11: R_X86_64_PC32 f-0x4
15: 48 89 c5 mov %rax,%rbp
18: 48 85 ed test %rbp,%rbp
1b: 74 0d je 2a <fn+0x2a>
1d: 48 85 db test %rbx,%rbx
20: 74 08 je 2a <fn+0x2a>
22: 5a pop %rdx
23: 5b pop %rbx
24: 5d pop %rbp
25: e9 00 00 00 00 jmpq 2a <fn+0x2a>
26: R_X86_64_PC32 g-0x4
2a: 58 pop %rax
2b: 5b pop %rbx
2c: 5d pop %rbp
2d: c3 retq
Which is 1 byte more than -O2. I would think that -Os would be smaller.
-- Steve