On Tue, Jun 14, 2011 at 12:06 AM, Andrew Lutomirski<luto@xxxxxxx> wrote:On Mon, Jun 13, 2011 at 4:45 AM, Rakib Mullick<rakib.mullick@xxxxxxxxx> wrote:I'm using 3.0.0-rc2 (lastly I pulled tip tree 3 days ago). I'veOn Mon, Jun 13, 2011 at 10:54 AM, Rakib Mullick<rakib.mullick@xxxxxxxxx> wrote:On Mon, Jun 13, 2011 at 8:52 AM, Andrew Lutomirski<luto@xxxxxxx> wrote:Here is my GCC version - gcc version 4.5.1 20100924 (Red Hat 4.5.1-4)On Sun, Jun 12, 2011 at 1:12 AM, Rakib Mullick<rakib.mullick@xxxxxxxxx> wrote:I don't have much knowledge of advance assembly, so I really don'tOn Sat, Jun 11, 2011 at 5:01 PM, Andrew Lutomirski<luto@xxxxxxx> wrote:On Sat, Jun 11, 2011 at 3:31 AM, Rakib Mullick<rakib.mullick@xxxxxxxxx> wrote:
I think there are three separate issues here:
1. Can ret be used uninitialized? I say no, even as seen by the
compiler. If vsyscall_nr is 0, 1, or 2, then ret is initialized. If
vsyscall_nr is 3, then the BUG gets hit. BUG is defined as some
assembly magic followed by unreachable(), and the compiler is supposed
to know that code after unreachable() is qunreachable. So how can ret
be used uninitialized?
understand that part - how BUG handles this. If it really makes sure
that, it will handle it properly then I think you can drop this patch.
What version of gcc do you have? gcc (GCC) 4.6.0 20110530 (Red HatCurrently, I'm replying from outside my home. I'll let you know when
4.6.0-9) does not produce this warning.
I'm back home.
(GCC). I'm using Fedora 14.
I also have gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) on another box,
and I still can't reproduce this.
Can you tell me which git revision you're building and send me your
.config and the output of:
attached the .config (config.log).
$ touch arch/x86/kernel/vsyscall_64.oOutput of the above steps are attached (vsyscall_64.log). Hope that will help.
$ make V=1 arch/x86/kernel/vsyscall_64.o