Am 5. August 2020 21:03:28 MESZ schrieb Tom Rini <tr...@konsulko.com>: >On Wed, Aug 05, 2020 at 12:56:17PM -0600, Simon Glass wrote: >> Hi Tom, >> >> On Wed, 5 Aug 2020 at 12:37, Tom Rini <tr...@konsulko.com> wrote: >> > >> > On Wed, Aug 05, 2020 at 08:31:55PM +0200, Heinrich Schuchardt >wrote: >> > > On 05.08.20 14:56, Tom Rini wrote: >> > > > On Wed, Aug 05, 2020 at 02:54:05PM +0200, Heinrich Schuchardt >wrote: >> > > >> On 05.08.20 14:18, Tom Rini wrote: >> > > >>> On Sun, Jul 26, 2020 at 08:27:35PM -0600, Simon Glass wrote: >> > > >>> >> > > >>>> At present if CONFIG_LOG enabled, putting LOG_DEBUG at the >top of a file >> > > >>>> (before log.h inclusion) causes _log() to be executed for >every log() >> > > >>>> call, regardless of the build- or run-time logging level. >> > > >>>> >> > > >>>> However there is no guarantee that the log record will >actually be >> > > >>>> displayed. If the current log level is lower than LOGL_DEBUG >then it will >> > > >>>> not be. >> > > >>>> >> > > >>>> Add a way to signal that the log record should always be >displayed and >> > > >>>> update log_passes_filters() to handle this. >> > > >>>> >> > > >>>> Signed-off-by: Simon Glass <s...@chromium.org> >> > > >>> >> > > >>> This exposes an underlying problem with LOG and clang I >believe: >> > > >>> https://gitlab.denx.de/u-boot/u-boot/-/jobs/135789 >> > > >>> >> > > >> >> > > >> include/log.h:147:44: note: expanded from macro 'log' >> > > >> if (CONFIG_IS_ENABLED(LOG) && (_LOG_DEBUG || _l <= >> > > >> _LOG_MAX_LEVEL)) \ >> > > >> ^ >> > > >> drivers/misc/p2sb_emul.c:197:10: error: converting the enum >constant to >> > > >> a boolean [-Werror,-Wint-in-bool-context] >> > > >> >> > > >> This seems to be a Clang bug. _LOG_DEBUG is not an enum: >> > > >> >> > > >> #if CONFIG_IS_ENABLED(LOG) >> > > >> #ifdef LOG_DEBUG >> > > >> #define _LOG_DEBUG 1 >> > > >> #else >> > > >> #define _LOG_DEBUG 0 >> > > >> #endif >> > > >> >> > > >> So there seems to be a bug in the Clang you used. >> > > >> >> > > >> Compiling with clang on Debian Bullseye does not show the >problem: >> > > >> >> > > >> make HOSTCC=clang sandbox_defconfig >> > > >> make HOSTCC=clang CC=clang -j8 >> > > >> >> > > >> clang version 9.0.1-13 >> > > >> LLVM version 9.0.1 >> > > >> >> > > >> Which Clang version did you use? >> > > >> >> > > >> This is the change that added the test: >> > > >> https://reviews.llvm.org/D63082 >> > > >> >> > > >> -Wint-in-bool-context seems to be new in Clang 10. >> > > >> >> > > >> All over the U-Boot code we assume that a non-zero integer is >true. Do >> > > >> we really want to enable -Wint-in-bool-context? >> > > > >> > > > I'm using the official Clang 10 stable builds. >> > > > >> > > >> > > Do you really want to forbid using integers as booleans >> > > (-Wint-in-bool-context)? >> > >> > So, interesting. The Linux kernel isn't disabling this warning. >It's >> > mentioned in two commits, one of which is "clang found a bug here", >of >> > which this is not the case. The other is more like ours: >> > commit 968e5170939662341242812b9c82ef51cf140a33 >> > Author: Nathan Chancellor <natechancel...@gmail.com> >> > Date: Thu Sep 26 09:22:59 2019 -0700 >> > >> > tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN >macro >> > >> > After r372664 in clang, the IF_ASSIGN macro causes a couple >hundred >> > warnings along the lines of: >> > >> > kernel/trace/trace_output.c:1331:2: warning: converting the >enum >> > constant to a boolean [-Wint-in-bool-context] >> > kernel/trace/trace.h:409:3: note: expanded from macro >> > 'trace_assign_type' >> > IF_ASSIGN(var, ent, struct >ftrace_graph_ret_entry, >> > ^ >> > kernel/trace/trace.h:371:14: note: expanded from macro >'IF_ASSIGN' >> > WARN_ON(id && (entry)->type != id); \ >> > ^ >> > 264 warnings generated. >> > >> > This warning can catch issues with constructs like: >> > >> > if (state == A || B) >> > >> > where the developer really meant: >> > >> > if (state == A || state == B) >> > >> > This is currently the only occurrence of the warning in the >kernel >> > tree across defconfig, allyesconfig, allmodconfig for arm32, >arm64, >> > and x86_64. Add the implicit '!= 0' to the WARN_ON statement to >fix >> > the warnings and find potential issues in the future. >> > >> > Link: >https://github.com/llvm/llvm-project/commit/28b38c277a2941e9e891b2db30652cfd962f070b >> > Link: https://github.com/ClangBuiltLinux/linux/issues/686 >> > Link: >http://lkml.kernel.org/r/20190926162258.466321-1-natechancel...@gmail.com >> > >> > Reviewed-by: Nick Desaulniers <ndesaulni...@google.com> >> > Signed-off-by: Nathan Chancellor <natechancel...@gmail.com> >> > Signed-off-by: Steven Rostedt (VMware) <rost...@goodmis.org> >> > >> > Which is like our case, and reworking the test to be explicit. I >lean >> > towards that. >> >> Oh dear I really want to vote against that. >> >> if (x) >> >> should allow C to consider x to be a boolean. I am hitting this in >> Zephyr and feels like it is undoing a long-standing C feature, with >> major disruption, for no benefit I can detect. >> >> Hopefully I am misunderstanding what -Wint-in-bool-context means, and >> it just applies to enums? > >Yes, it's not the simple case, it's the complex case as noted in the >kernel commit message. Our change I believe would be: > >diff --git a/include/log.h b/include/log.h >index 2859ce1f2e72..91ca2e0523f7 100644 >--- a/include/log.h >+++ b/include/log.h >@@ -141,7 +141,7 @@ static inline int _log_nop(enum log_category_t cat, >enum log_level_t level, > /* Emit a log record if the level is less that the maximum */ > #define log(_cat, _level, _fmt, _args...) ({ \ > int _l = _level; \ >- if (CONFIG_IS_ENABLED(LOG) && (_l <= _LOG_MAX_LEVEL || _LOG_DEBUG)) \ >+ if (CONFIG_IS_ENABLED(LOG) && (_l <= _LOG_MAX_LEVEL || _LOG_DEBUG == >1)) \
Why wouldn't we define _LOG_DEBUG as true or false? Shouldn't clang know that true is boolean? > _log((enum log_category_t)(_cat), _l, __FILE__, __LINE__, \ > __func__, \ > pr_fmt(_fmt), ##_args); \ > >It's not a new warning from clang (We've been on LLVM-10 since >February), it's only that the logging code is now being run through it >via CI.
