From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Thu, 18 Sep 2014 11:39:44 +0200 Subject: [U-Boot] [PATCH 3/3] compiler.h: remove duplicated uninitialized_var In-Reply-To: <20140918111434.70CC.AA925319@jp.panasonic.com> References: <1410978828-20292-1-git-send-email-jeroen@myspectrum.nl> <1410978828-20292-4-git-send-email-jeroen@myspectrum.nl> <20140918111434.70CC.AA925319@jp.panasonic.com> Message-ID: <541AA860.8080101@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Masahiro, On 18-09-14 04:14, Masahiro Yamada wrote: >> Since clang has a different definition for uninitialized_var >> it will complain that it is redefined in include/compiler.h. >> Since these are already defined in linux/compiler.h just remove >> this instance. >> >> Cc: Masahiro Yamada >> Cc: Tom Rini >> Signed-off-by: Jeroen Hofstee > > > I don't mind this patch but it has made me realize > another problem. > > > We have both include/compiler.h and include/linux/compiler.h. > Some sources use tha former and others use the latter. > > I don't know how to use the right one in the right place. no me neither, although it seems arch / drivers tend to use linux/compiler.h more while tools include compiler.h more. > Header file policy is one of the biggest problem in U-boot. > > Everyone has added ugly work-arounds to solve his own problem > without correct views or judgement. > > >> diff --git a/include/compiler.h b/include/compiler.h >> index 9afc11b..1451916 100644 >> --- a/include/compiler.h >> +++ b/include/compiler.h >> @@ -129,9 +129,6 @@ typedef unsigned long int uintptr_t; >> >> #endif /* USE_HOSTCC */ >> >> -/* compiler options */ >> -#define uninitialized_var(x) x = x >> - >> #define likely(x) __builtin_expect(!!(x), 1) >> #define unlikely(x) __builtin_expect(!!(x), 0) >> > > I am not sure if likely(x) and unlikely(x) should also > duplicated here. > yup I wondered about that too. likely / unlikely are used a lot more though then the isolated use of uninitialized_var. And as they don't cause any problems (the definitions are the same) I let them alone, but I think they should be removed as well some day. Regards, Jeroen