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.
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. Cast the negated values back to u8.
This fixes several warnings like
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. Cast the negated values back to u8.
This fixes several warnings like
46 matches
Mail list logo
