On Wed, Jun 20, 2018 at 10:02:15AM +0200, Paolo Bonzini wrote:
> On 20/06/2018 01:45, Matthias Kaehlcke wrote:
> >
> > v4.16 with an x86 allyesconfig and a few drivers disabled since they
> > don't build with clang (yet):
> >
> > 16 occurrences of -Wconstant-conversion, including the ones fixed
On Wed, Jun 20, 2018 at 10:02:15AM +0200, Paolo Bonzini wrote:
> On 20/06/2018 01:45, Matthias Kaehlcke wrote:
> >
> > v4.16 with an x86 allyesconfig and a few drivers disabled since they
> > don't build with clang (yet):
> >
> > 16 occurrences of -Wconstant-conversion, including the ones fixed
On 20/06/2018 01:45, Matthias Kaehlcke wrote:
>
> v4.16 with an x86 allyesconfig and a few drivers disabled since they
> don't build with clang (yet):
>
> 16 occurrences of -Wconstant-conversion, including the ones fixed by
> this patch. Certainly no need for an endless churn of patches, and
>
On 20/06/2018 01:45, Matthias Kaehlcke wrote:
>
> v4.16 with an x86 allyesconfig and a few drivers disabled since they
> don't build with clang (yet):
>
> 16 occurrences of -Wconstant-conversion, including the ones fixed by
> this patch. Certainly no need for an endless churn of patches, and
>
On Tue, Jun 19, 2018 at 05:18:02PM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 16:45 -0700, Matthias Kaehlcke wrote:
> > On Tue, Jun 19, 2018 at 02:55:05PM -0700, Joe Perches wrote:
> > > Well, you advocate to disable a possibly useful warning globally ...
> > > You're advocating for making
On Tue, Jun 19, 2018 at 05:18:02PM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 16:45 -0700, Matthias Kaehlcke wrote:
> > On Tue, Jun 19, 2018 at 02:55:05PM -0700, Joe Perches wrote:
> > > Well, you advocate to disable a possibly useful warning globally ...
> > > You're advocating for making
On Tue, 2018-06-19 at 16:45 -0700, Matthias Kaehlcke wrote:
> On Tue, Jun 19, 2018 at 02:55:05PM -0700, Joe Perches wrote:
> > Well, you advocate to disable a possibly useful warning globally ...
> > You're advocating for making the code more complex/ugly for a
> > condition where the result is
On Tue, 2018-06-19 at 16:45 -0700, Matthias Kaehlcke wrote:
> On Tue, Jun 19, 2018 at 02:55:05PM -0700, Joe Perches wrote:
> > Well, you advocate to disable a possibly useful warning globally ...
> > You're advocating for making the code more complex/ugly for a
> > condition where the result is
On Tue, Jun 19, 2018 at 02:55:05PM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 14:10 -0700, Matthias Kaehlcke wrote:
> > On Tue, Jun 19, 2018 at 12:11:27PM -0700, Joe Perches wrote:
> > > -Wconstant-conversion is only issued when a *constant value* is assigned
> > > to
> > an incompatible
On Tue, Jun 19, 2018 at 02:55:05PM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 14:10 -0700, Matthias Kaehlcke wrote:
> > On Tue, Jun 19, 2018 at 12:11:27PM -0700, Joe Perches wrote:
> > > -Wconstant-conversion is only issued when a *constant value* is assigned
> > > to
> > an incompatible
On Tue, 2018-06-19 at 14:10 -0700, Matthias Kaehlcke wrote:
> On Tue, Jun 19, 2018 at 12:11:27PM -0700, Joe Perches wrote:
> > -Wconstant-conversion is only issued when a *constant value* is assigned to
> an incompatible type.
>
> > Trying to allow a "make W=3" to be compiler warning message free
On Tue, 2018-06-19 at 14:10 -0700, Matthias Kaehlcke wrote:
> On Tue, Jun 19, 2018 at 12:11:27PM -0700, Joe Perches wrote:
> > -Wconstant-conversion is only issued when a *constant value* is assigned to
> an incompatible type.
>
> > Trying to allow a "make W=3" to be compiler warning message free
On Tue, Jun 19, 2018 at 12:11:27PM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 11:36 -0700, Matthias Kaehlcke wrote:
> > On Tue, Jun 19, 2018 at 11:07:47AM -0700, Joe Perches wrote:
> > > On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> > > > On 19/06/2018 19:23, Joe Perches wrote:
On Tue, Jun 19, 2018 at 12:11:27PM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 11:36 -0700, Matthias Kaehlcke wrote:
> > On Tue, Jun 19, 2018 at 11:07:47AM -0700, Joe Perches wrote:
> > > On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> > > > On 19/06/2018 19:23, Joe Perches wrote:
On Tue, 2018-06-19 at 11:36 -0700, Matthias Kaehlcke wrote:
> On Tue, Jun 19, 2018 at 11:07:47AM -0700, Joe Perches wrote:
> > On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> > > On 19/06/2018 19:23, Joe Perches wrote:
> > > > On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
>
On Tue, 2018-06-19 at 11:36 -0700, Matthias Kaehlcke wrote:
> On Tue, Jun 19, 2018 at 11:07:47AM -0700, Joe Perches wrote:
> > On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> > > On 19/06/2018 19:23, Joe Perches wrote:
> > > > On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
>
On Tue, Jun 19, 2018 at 07:13:41PM +0200, Paolo Bonzini wrote:
> On 19/06/2018 19:08, Nick Desaulniers wrote:
> >> This one really makes the code uglier though, so I'm not really inclined
> >> to applying the patch.
> > Note that of the three variables (w, u, x), only u is used later on.
> > What
On Tue, Jun 19, 2018 at 07:13:41PM +0200, Paolo Bonzini wrote:
> On 19/06/2018 19:08, Nick Desaulniers wrote:
> >> This one really makes the code uglier though, so I'm not really inclined
> >> to applying the patch.
> > Note that of the three variables (w, u, x), only u is used later on.
> > What
On Tue, Jun 19, 2018 at 11:07:47AM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> > On 19/06/2018 19:23, Joe Perches wrote:
> > > On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
> > > > On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini
> > > > wrote:
On Tue, Jun 19, 2018 at 11:07:47AM -0700, Joe Perches wrote:
> On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> > On 19/06/2018 19:23, Joe Perches wrote:
> > > On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
> > > > On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini
> > > > wrote:
On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> On 19/06/2018 19:23, Joe Perches wrote:
> > On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
> > > On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
> > > >
> > > > On 15/06/2018 20:45, Nick Desaulniers wrote:
> > > > > >
>
On Tue, 2018-06-19 at 19:35 +0200, Paolo Bonzini wrote:
> On 19/06/2018 19:23, Joe Perches wrote:
> > On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
> > > On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
> > > >
> > > > On 15/06/2018 20:45, Nick Desaulniers wrote:
> > > > > >
>
On 19/06/2018 19:23, Joe Perches wrote:
> On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
>> On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
>>>
>>> On 15/06/2018 20:45, Nick Desaulniers wrote:
>
>> In any case I think it it preferable to fix the code over disabling
>>
On 19/06/2018 19:23, Joe Perches wrote:
> On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
>> On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
>>>
>>> On 15/06/2018 20:45, Nick Desaulniers wrote:
>
>> In any case I think it it preferable to fix the code over disabling
>>
On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
> On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
> >
> > On 15/06/2018 20:45, Nick Desaulniers wrote:
> > > >
> > > > > In any case I think it it preferable to fix the code over disabling
> > > > > the warning, unless the warning
On Tue, 2018-06-19 at 10:08 -0700, Nick Desaulniers wrote:
> On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
> >
> > On 15/06/2018 20:45, Nick Desaulniers wrote:
> > > >
> > > > > In any case I think it it preferable to fix the code over disabling
> > > > > the warning, unless the warning
On 19/06/2018 19:08, Nick Desaulniers wrote:
>> This one really makes the code uglier though, so I'm not really inclined
>> to applying the patch.
> Note that of the three variables (w, u, x), only u is used later on.
> What about declaring them as negated with the cast, that way there's
> no cast
On 19/06/2018 19:08, Nick Desaulniers wrote:
>> This one really makes the code uglier though, so I'm not really inclined
>> to applying the patch.
> Note that of the three variables (w, u, x), only u is used later on.
> What about declaring them as negated with the cast, that way there's
> no cast
On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
>
> On 15/06/2018 20:45, Nick Desaulniers wrote:
> >>
> >>> In any case I think it it preferable to fix the code over disabling
> >>> the warning, unless the warning is bogus or there are just too many
> >>> occurrences.
> >> Maybe.
> >
On Tue, Jun 19, 2018 at 8:19 AM Paolo Bonzini wrote:
>
> On 15/06/2018 20:45, Nick Desaulniers wrote:
> >>
> >>> In any case I think it it preferable to fix the code over disabling
> >>> the warning, unless the warning is bogus or there are just too many
> >>> occurrences.
> >> Maybe.
> >
On 15/06/2018 20:45, Nick Desaulniers wrote:
>>
>>> In any case I think it it preferable to fix the code over disabling
>>> the warning, unless the warning is bogus or there are just too many
>>> occurrences.
>> Maybe.
> Spurious warning today, actual bug tomorrow? I prefer to not to
> disable
On 15/06/2018 20:45, Nick Desaulniers wrote:
>>
>>> In any case I think it it preferable to fix the code over disabling
>>> the warning, unless the warning is bogus or there are just too many
>>> occurrences.
>> Maybe.
> Spurious warning today, actual bug tomorrow? I prefer to not to
> disable
Hi Matthias,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v4.17 next-20180615]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Matthias,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v4.17 next-20180615]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Fri, Jun 15, 2018 at 11:40 AM Joe Perches wrote:
>
> On Fri, 2018-06-15 at 11:29 -0700, Matthias Kaehlcke wrote:
> > On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote:
> > > On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> > > > On Fri, Jun 15, 2018 at 10:47 AM Matthias
On Fri, Jun 15, 2018 at 11:40 AM Joe Perches wrote:
>
> On Fri, 2018-06-15 at 11:29 -0700, Matthias Kaehlcke wrote:
> > On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote:
> > > On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> > > > On Fri, Jun 15, 2018 at 10:47 AM Matthias
On Fri, 2018-06-15 at 11:29 -0700, Matthias Kaehlcke wrote:
> On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote:
> > On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> > > On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke
> > > wrote:
> > > >
> > > >
On Fri, 2018-06-15 at 11:29 -0700, Matthias Kaehlcke wrote:
> On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote:
> > On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> > > On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke
> > > wrote:
> > > >
> > > >
On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote:
> On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> > On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke
> > wrote:
> > >
> > > update_permission_bitmask() negates u8 bitmask values and assigns them
> > > to variables of
On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote:
> On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> > On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke
> > wrote:
> > >
> > > update_permission_bitmask() negates u8 bitmask values and assigns them
> > > to variables of
On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke wrote:
> >
> > update_permission_bitmask() negates u8 bitmask values and assigns them
> > to variables of type u8. Since the MSB is set in the bitmask values the
> > compiler expands
On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote:
> On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke wrote:
> >
> > update_permission_bitmask() negates u8 bitmask values and assigns them
> > to variables of type u8. Since the MSB is set in the bitmask values the
> > compiler expands
On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke wrote:
>
> update_permission_bitmask() negates u8 bitmask values and assigns them
> to variables of type u8. Since the MSB is set in the bitmask values the
> compiler expands the negated values to int, which then are assigned to
> u8 variables.
On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke wrote:
>
> update_permission_bitmask() negates u8 bitmask values and assigns them
> to variables of type u8. Since the MSB is set in the bitmask values the
> compiler expands the negated values to int, which then are assigned to
> u8 variables.
44 matches
Mail list logo