Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1638523 > unrolled thread

[PATCH] drm/mm: fix duplicate 'const' declaration specifier

Started byNick Desaulniers <nick.desaulniers@gmail.com>
First post2017-05-10 05:30 +0200
Last post2017-05-10 08:00 +0200
Articles 3 — 1 participant

Back to article view | Back to linux.kernel


Contents

  [PATCH] drm/mm: fix duplicate 'const' declaration specifier Nick Desaulniers <nick.desaulniers@gmail.com> - 2017-05-10 05:30 +0200
    Re: [PATCH] drm/mm: fix duplicate 'const' declaration specifier Nick Desaulniers <nick.desaulniers@gmail.com> - 2017-05-10 05:40 +0200
    Re: [PATCH] drm/mm: fix duplicate 'const' declaration specifier Nick Desaulniers <nick.desaulniers@gmail.com> - 2017-05-10 08:00 +0200

#1638523 — [PATCH] drm/mm: fix duplicate 'const' declaration specifier

FromNick Desaulniers <nick.desaulniers@gmail.com>
Date2017-05-10 05:30 +0200
Subject[PATCH] drm/mm: fix duplicate 'const' declaration specifier
Message-ID<tFqu5-34C-5@gated-at.bofh.it>
Found with -Wduplicate-decl-specifier, a relatively new compiler flag in
GCC7, and Clang.

list_for_each_entry() eventually calls container_of(), which marks the
loop variable as const.  The first argument to list_for_each_entry() is
a type, which should not already be marked const, otherwise the loop
variable is marked const twice.

While this particular call site does not modify the loop variable,
trying to do so would already result in a compile time failure, so we
can remove the current const. Other call sites do not mark the loop
variable const.

Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
---
 include/drm/drm_mm.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 49b292e98fec..6716af9290c9 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -281,7 +281,7 @@ static inline u64 drm_mm_hole_node_start(const struct drm_mm_node *hole_node)
 	return __drm_mm_hole_node_start(hole_node);
 }
 
-static inline u64 __drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
+static inline u64 __drm_mm_hole_node_end(struct drm_mm_node *hole_node)
 {
 	return list_next_entry(hole_node, node_list)->start;
 }
@@ -297,7 +297,7 @@ static inline u64 __drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
  * Returns:
  * End of the subsequent hole.
  */
-static inline u64 drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
+static inline u64 drm_mm_hole_node_end(struct drm_mm_node *hole_node)
 {
 	return __drm_mm_hole_node_end(hole_node);
 }
-- 
2.11.0

[toc] | [next] | [standalone]


#1638529

FromNick Desaulniers <nick.desaulniers@gmail.com>
Date2017-05-10 05:40 +0200
Message-ID<tFqDL-3bV-7@gated-at.bofh.it>
In reply to#1638523
ah seems like there's more of these:

drivers/gpu/drm/drm_mm.c:922

surprised compiling drivers/gpu/drm/drm_mm.o did not catch this the
first time...

[toc] | [prev] | [next] | [standalone]


#1638570

FromNick Desaulniers <nick.desaulniers@gmail.com>
Date2017-05-10 08:00 +0200
Message-ID<tFsPf-5e7-3@gated-at.bofh.it>
In reply to#1638523
Please disregard this patch.  I think I may have found a bug in Clang,
or at least an incompatibility with GCC 7.1.

Clang bug: https://bugs.llvm.org/show_bug.cgi?id=32985

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web