Bug 105271

Summary: build fails on bad if (gcc 5.1)
Product: Tracing/Profiling Reporter: René Bertin (rjvbertin)
Component: Perf toolAssignee: Arnaldo Carvalho de Melo (acme)
Status: RESOLVED DUPLICATE    
Severity: blocking CC: colin.pitrat+kernelbug, jolsa, jolsa
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.14.53 Subsystem:
Regression: No Bisected commit-id:
Attachments: patch that fixes the issue following what must be the code author's intention

Description René Bertin 2015-09-30 08:22:34 UTC 
Created attachment 189081 [details]
patch that fixes the issue following what must be the code author's intention

More than a year after [https://bugzilla.kernel.org/show_bug.cgi?id=76751] was filed, gcc-5.1 errors on the expression that was signalled in that bug report:

gcc -o ui/browser.o -c  -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-aliasing=3 -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -DHAVE_ARCH_X86_64_SUPPORT -DHAVE_PERF_REGS_SUPPORT -Werror -O6 -fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra -std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2 -Ilinux-3.14.53/tools/perf/util/include -Ilinux-3.14.53/tools/perf/arch/x86/include -Ilinux-3.14.53/tools/include/ -Ilinux-3.14.53/arch/x86/include/uapi -Ilinux-3.14.53/arch/x86/include -Ilinux-3.14.53/include/uapi -Ilinux-3.14.53/include -Ilinux-3.14.53/tools/perf/util -Ilinux-3.14.53/tools/perf -Ilinux-3.14.53/tools/lib/ -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_DWARF_SUPPORT  -DNO_LIBUNWIND_DEBUG_FRAME -DHAVE_LIBUNWIND_SUPPORT  -DHAVE_LIBAUDIT_SUPPORT -I/usr/include/slang -DHAVE_SLANG_SUPPORT -DHAVE_GTK2_SUPPORT -DHAVE_TIMERFD_SUPPORT -DHAVE_LIBBFD_SUPPORT -DHAVE_ON_EXIT_SUPPORT -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT -DENABLE_SLFUTURE_CONST ui/browser.c
ui/browser.c: In function ‘ui_browser__warning’:
ui/browser.c:199:20: error: comparison of constant ‘-3’ with boolean expression is always false [-Werror=bool-compare]
          timeout)) == K_RESIZE)
                    ^
cc1: all warnings being treated as errors
make[2]: *** [ui/browser.o] Error 1

It seems clear that the OP's assumption is correct that this is a case of '==' being used instead of '=' .
Comment 1 Jiri Olsa 2015-09-30 08:54:50 UTC 
hum, it works on my setup with gcc 5.1:

[jolsa@krava perf]$ make
  BUILD:   Doing 'make -j4' parallel build
  CC       ui/browser.o
  LD       ui/libperf-in.o
  LD       libperf-in.o
  AR       libperf.a
  LINK     perf
  LINK     libperf-gtk.so
[jolsa@krava perf]$ gcc --version
gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

it's the latest Arnaldo's tree, could you please retest?
Comment 2 René Bertin 2015-09-30 09:30:32 UTC 
Retest in what sense? I did not add the -Werror=bool-compare option to the Makefile, and if the source hasn't been modified after the 3.14.53 release tarball was created I'd get the same failure.
The real issue here is the syntax error on line 199, not whether or not the build is done with -Werror=bool-compare ...

I'm using

$ make -w -C tools -j2 perf

I did set the optimisation to -O3 in tools/perf/config/feature-checks/Makefile, though I cannot imagine that changes anything to -Werror settings.
I'm using "gcc (Ubuntu 5.1.0-0ubuntu11~14.04.1) 5.1.0"; maybe the exact set of warnings that become errors (or warnings that are enabled by default) is under control of the packager?
Comment 3 Colin Pitrat 2016-04-30 07:32:38 UTC 
This has been fixed in https://bugzilla.kernel.org/show_bug.cgi?id=76751 and should be closed shouldn't it ?
Comment 4 Colin Pitrat 2016-05-02 20:01:57 UTC 

*** This bug has been marked as a duplicate of bug 76751 ***