All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	clang-built-linux@googlegroups.com,
	"Nathan Chancellor" <natechancellor@gmail.com>,
	"Michel Dänzer" <michel@daenzer.net>
Subject: Re: [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
Date: Fri, 14 Feb 2020 13:49:31 +0200	[thread overview]
Message-ID: <87o8u1wfqs.fsf@intel.com> (raw)
In-Reply-To: <158166913989.4660.10674824117292988120@skylake-alporthouse-com>

On Fri, 14 Feb 2020, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Jani Nikula (2020-02-14 06:36:15)
>> On Thu, 13 Feb 2020, Nathan Chancellor <natechancellor@gmail.com> wrote:
>> > A recent commit in clang added -Wtautological-compare to -Wall, which is
>> > enabled for i915 after -Wtautological-compare is disabled for the rest
>> > of the kernel so we see the following warning on x86_64:
>> >
>> >  ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning:
>> >  result of comparison of constant 576460752303423487 with expression of
>> >  type 'unsigned int' is always false
>> >  [-Wtautological-constant-out-of-range-compare]
>> >          if (unlikely(remain > N_RELOC(ULONG_MAX)))
>> >             ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
>> >  ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
>> >  # define unlikely(x)    __builtin_expect(!!(x), 0)
>> >                                             ^
>> >  1 warning generated.
>> >
>> > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not
>> > account for the case where this file is built for 32-bit x86, where
>> > ULONG_MAX == UINT_MAX and this check is still relevant.
>> >
>> > Cast remain to unsigned long, which keeps the generated code the same
>> > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and
>> > the warning is silenced so we can catch more potential issues in the
>> > future.
>> >
>> > Link: https://github.com/ClangBuiltLinux/linux/issues/778
>> > Suggested-by: Michel Dänzer <michel@daenzer.net>
>> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>> 
>> Works for me as a workaround,
>
> But the whole point was that the compiler could see that it was
> impossible and not emit the code. Doesn't this break that?

It seems that goal and the warning are fundamentally incompatible.

Back to the original patch?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	clang-built-linux@googlegroups.com,
	"Nathan Chancellor" <natechancellor@gmail.com>,
	"Michel Dänzer" <michel@daenzer.net>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
Date: Fri, 14 Feb 2020 13:49:31 +0200	[thread overview]
Message-ID: <87o8u1wfqs.fsf@intel.com> (raw)
In-Reply-To: <158166913989.4660.10674824117292988120@skylake-alporthouse-com>

On Fri, 14 Feb 2020, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Jani Nikula (2020-02-14 06:36:15)
>> On Thu, 13 Feb 2020, Nathan Chancellor <natechancellor@gmail.com> wrote:
>> > A recent commit in clang added -Wtautological-compare to -Wall, which is
>> > enabled for i915 after -Wtautological-compare is disabled for the rest
>> > of the kernel so we see the following warning on x86_64:
>> >
>> >  ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning:
>> >  result of comparison of constant 576460752303423487 with expression of
>> >  type 'unsigned int' is always false
>> >  [-Wtautological-constant-out-of-range-compare]
>> >          if (unlikely(remain > N_RELOC(ULONG_MAX)))
>> >             ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
>> >  ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
>> >  # define unlikely(x)    __builtin_expect(!!(x), 0)
>> >                                             ^
>> >  1 warning generated.
>> >
>> > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not
>> > account for the case where this file is built for 32-bit x86, where
>> > ULONG_MAX == UINT_MAX and this check is still relevant.
>> >
>> > Cast remain to unsigned long, which keeps the generated code the same
>> > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and
>> > the warning is silenced so we can catch more potential issues in the
>> > future.
>> >
>> > Link: https://github.com/ClangBuiltLinux/linux/issues/778
>> > Suggested-by: Michel Dänzer <michel@daenzer.net>
>> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>> 
>> Works for me as a workaround,
>
> But the whole point was that the compiler could see that it was
> impossible and not emit the code. Doesn't this break that?

It seems that goal and the warning are fundamentally incompatible.

Back to the original patch?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com,
	"Nathan Chancellor" <natechancellor@gmail.com>,
	"Michel Dänzer" <michel@daenzer.net>
Subject: Re: [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
Date: Fri, 14 Feb 2020 13:49:31 +0200	[thread overview]
Message-ID: <87o8u1wfqs.fsf@intel.com> (raw)
In-Reply-To: <158166913989.4660.10674824117292988120@skylake-alporthouse-com>

On Fri, 14 Feb 2020, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Jani Nikula (2020-02-14 06:36:15)
>> On Thu, 13 Feb 2020, Nathan Chancellor <natechancellor@gmail.com> wrote:
>> > A recent commit in clang added -Wtautological-compare to -Wall, which is
>> > enabled for i915 after -Wtautological-compare is disabled for the rest
>> > of the kernel so we see the following warning on x86_64:
>> >
>> >  ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning:
>> >  result of comparison of constant 576460752303423487 with expression of
>> >  type 'unsigned int' is always false
>> >  [-Wtautological-constant-out-of-range-compare]
>> >          if (unlikely(remain > N_RELOC(ULONG_MAX)))
>> >             ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
>> >  ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
>> >  # define unlikely(x)    __builtin_expect(!!(x), 0)
>> >                                             ^
>> >  1 warning generated.
>> >
>> > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not
>> > account for the case where this file is built for 32-bit x86, where
>> > ULONG_MAX == UINT_MAX and this check is still relevant.
>> >
>> > Cast remain to unsigned long, which keeps the generated code the same
>> > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and
>> > the warning is silenced so we can catch more potential issues in the
>> > future.
>> >
>> > Link: https://github.com/ClangBuiltLinux/linux/issues/778
>> > Suggested-by: Michel Dänzer <michel@daenzer.net>
>> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>> 
>> Works for me as a workaround,
>
> But the whole point was that the compiler could see that it was
> impossible and not emit the code. Doesn't this break that?

It seems that goal and the warning are fundamentally incompatible.

Back to the original patch?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2020-02-14 11:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14  5:47 [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma Nathan Chancellor
2020-02-14  5:47 ` Nathan Chancellor
2020-02-14  5:47 ` [Intel-gfx] " Nathan Chancellor
2020-02-14  6:31 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-02-14  6:36 ` [PATCH] " Jani Nikula
2020-02-14  6:36   ` Jani Nikula
2020-02-14  6:36   ` [Intel-gfx] " Jani Nikula
2020-02-14  8:32   ` Chris Wilson
2020-02-14  8:32     ` Chris Wilson
2020-02-14  8:32     ` [Intel-gfx] " Chris Wilson
2020-02-14 11:49     ` Jani Nikula [this message]
2020-02-14 11:49       ` Jani Nikula
2020-02-14 11:49       ` [Intel-gfx] " Jani Nikula
2020-02-14 15:36       ` Michel Dänzer
2020-02-14 15:36         ` Michel Dänzer
2020-02-14 15:36         ` [Intel-gfx] " Michel Dänzer
2020-03-16 21:41         ` Nick Desaulniers
2020-03-16 21:41           ` Nick Desaulniers
2020-03-16 21:41           ` [Intel-gfx] " Nick Desaulniers
2020-03-26 20:11           ` Nathan Chancellor
2020-03-26 20:11             ` Nathan Chancellor
2020-03-26 20:11             ` [Intel-gfx] " Nathan Chancellor
2020-03-26 22:15             ` Jani Nikula
2020-03-26 22:15               ` Jani Nikula
2020-03-26 22:15               ` [Intel-gfx] " Jani Nikula
2020-02-14 13:46     ` Nathan Chancellor
2020-02-14 13:46       ` Nathan Chancellor
2020-02-14 13:46       ` [Intel-gfx] " Nathan Chancellor
2020-02-17 17:06 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2020-03-17  0:13 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Cast remain to unsigned long in eb_relocate_vma (rev2) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8u1wfqs.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    --cc=natechancellor@gmail.com \
    --cc=rodrigo.vivi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.