Hi Tom,
On Wed, 5 Aug 2020 at 12:37, Tom Rini trini@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 sjg@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 natechancellor@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-natechancellor@gmail.com Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@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?
Regards, Simon