On Wed, Feb 27, 2019 at 09:09:40AM -0500, Qian Cai wrote:
> On Mon, 2019-02-25 at 16:07 -0800, Linus Torvalds wrote:
> > On Mon, Feb 25, 2019 at 4:03 PM Qian Cai wrote:
> > > >
> > > > Of course, that's just gcc. I have no idea what llvm ends up doing.
> > >
> > > Clang 7.0:
> > >
> > > # clang
On Wed, 2019-02-27 at 09:09 -0500, Qian Cai wrote:
> On Mon, 2019-02-25 at 16:07 -0800, Linus Torvalds wrote:
> > On Mon, Feb 25, 2019 at 4:03 PM Qian Cai wrote:
> > > >
> > > > Of course, that's just gcc. I have no idea what llvm ends up doing.
> > >
> > > Clang 7.0:
> > >
> > > # clang -O2 -
On Mon, 2019-02-25 at 16:07 -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2019 at 4:03 PM Qian Cai wrote:
> > >
> > > Of course, that's just gcc. I have no idea what llvm ends up doing.
> >
> > Clang 7.0:
> >
> > # clang -O2 -S -Wall /tmp/test.c
> > /tmp/test.c:46:6: warning: variable 'ret' i
On Mon, Feb 25, 2019 at 04:07:12PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2019 at 4:03 PM Qian Cai wrote:
> > >
> > > Of course, that's just gcc. I have no idea what llvm ends up doing.
> >
> > Clang 7.0:
> >
> > # clang -O2 -S -Wall /tmp/test.c
> > /tmp/test.c:46:6: warning: variable 're
On Mon, Feb 25, 2019 at 4:03 PM Qian Cai wrote:
> >
> > Of course, that's just gcc. I have no idea what llvm ends up doing.
>
> Clang 7.0:
>
> # clang -O2 -S -Wall /tmp/test.c
> /tmp/test.c:46:6: warning: variable 'ret' is used uninitialized whenever 'if'
> condition is false [-Wsometimes-uniniti
On 2/25/19 6:58 PM, Linus Torvalds wrote:
> On Mon, Feb 25, 2019 at 2:34 PM Linus Torvalds
> wrote:
>>
>> On Mon, Feb 25, 2019 at 12:34 PM Hugh Dickins wrote:
>>>
>>> Seems like a gcc bug? But I don't have a decent recent gcc to hand
>>> to submit a proper report, hope someone else can shed li
On Mon, Feb 25, 2019 at 2:34 PM Linus Torvalds
wrote:
>
> On Mon, Feb 25, 2019 at 12:34 PM Hugh Dickins wrote:
> >
> > Seems like a gcc bug? But I don't have a decent recent gcc to hand
> > to submit a proper report, hope someone else can shed light on it.
>
> I don't have a _very_ recent gcc eit
On Mon, Feb 25, 2019 at 12:34 PM Hugh Dickins wrote:
>
> Seems like a gcc bug? But I don't have a decent recent gcc to hand
> to submit a proper report, hope someone else can shed light on it.
I don't have a _very_ recent gcc either, but with gcc-8.2.1 the
attached test-case gives me:
[torval
On Mon, 25 Feb 2019, Linus Torvalds wrote:
> On Fri, Feb 22, 2019 at 10:35 PM Hugh Dickins wrote:
> >
> > When we made the shmem_reserve_inode call in shmem_link conditional, we
> > forgot to update the declaration for ret so that it always has a known
> > value. Dan Carpenter pointed out this de
On Fri, Feb 22, 2019 at 10:35 PM Hugh Dickins wrote:
>
> When we made the shmem_reserve_inode call in shmem_link conditional, we
> forgot to update the declaration for ret so that it always has a known
> value. Dan Carpenter pointed out this deficiency in the original patch.
Applied.
Side note:
From: "Darrick J. Wong"
When we made the shmem_reserve_inode call in shmem_link conditional, we
forgot to update the declaration for ret so that it always has a known
value. Dan Carpenter pointed out this deficiency in the original patch.
Fixes: 1062af920c07 ("tmpfs: fix link accounting when a
On Thu, Feb 21, 2019 at 2:21 PM Darrick J. Wong wrote:
>
> From: Darrick J. Wong
>
> When we made the shmem_reserve_inode call in shmem_link conditional, we
> forgot to update the declaration for ret so that it always has a known
> value. Dan Carpenter pointed out this deficiency in the original
From: Darrick J. Wong
When we made the shmem_reserve_inode call in shmem_link conditional, we
forgot to update the declaration for ret so that it always has a known
value. Dan Carpenter pointed out this deficiency in the original patch.
Fixes: "tmpfs: fix link accounting when a tmpfile is linke
13 matches
Mail list logo
