Bug 105271 - build fails on bad if (gcc 5.1)
Summary: build fails on bad if (gcc 5.1)
Status: RESOLVED DUPLICATE of bug 76751
Alias: None
Product: Tracing/Profiling
Classification: Unclassified
Component: Perf tool (show other bugs)
Hardware: All Linux
: P1 blocking
Assignee: Arnaldo Carvalho de Melo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-30 08:22 UTC by René Bertin
Modified: 2016-05-02 20:01 UTC (History)
3 users (show)

See Also:
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 (607 bytes, text/plain)
2015-09-30 08:22 UTC, René Bertin
Details

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 ***

Note You need to log in before you can comment on or make changes to this bug.