From: "tbaeder at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug server/26839] Systemtap build failures with clang
Date: Thu, 05 Nov 2020 09:21:37 +0000 [thread overview]
Message-ID: <bug-26839-6586-H0PpDUgedT@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-26839-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=26839
--- Comment #3 from Timm Bäder <tbaeder at redhat dot com> ---
Thanks for the reply, I'll work on this.
I changed the labs() line to:
unsigned min_score = abs(static_cast<signed>(target.size()) -
static_cast<signed>(it->size()));
since using the unsigned values generates another error:
util.cxx:1545:28: error: call to 'abs' is ambiguous
unsigned min_score = abs(target.size() - it->size());
^~~
/usr/include/stdlib.h:840:12: note: candidate function
extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/std_abs.h:56:3:
note: candidate function
abs(long __i) { return __builtin_labs(__i); }
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/std_abs.h:61:3:
note: candidate function
abs(long long __x) { return __builtin_llabs (__x); }
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/std_abs.h:71:3:
note: candidate function
abs(double __x)
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/std_abs.h:75:3:
note: candidate function
abs(float __x)
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/std_abs.h:79:3:
note: candidate function
abs(long double __x)
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/std_abs.h:85:3:
note: candidate function
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^
/usr/bin/../lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/bits/std_abs.h:103:3:
note: candidate function
abs(__float128 __x)
^
After adding the 'override' to emit_function() and emit_probe() in
translate.cxx as well as collect_derivation_chain() and
collect_derivation_pp_chain() in elaborate.h, I run into a few other issues:
1) set2 in bpf-bitset.h does not return anything from its assignment operator
but specifies a set2& return value. I fixed this with a 'return *this', but
maybe this is just dead code and should be removed?
2) set1_ref and set1_const_ref have a user-defined copy-assignment operator but
use the implicitly defined copy constructor, which clang warns about:
./bpf-bitset.h:108:19: error: definition of implicit copy constructor for
'set1_const_ref' is deprecated because it has a user-declared copy assignment
operator [-Werror,-Wdeprecated-copy]
set1_const_ref& operator= (const set1_const_ref &); // not present
^
./bpf-bitset.h:256:12: note: in implicit copy constructor for
'bpf::bitset::set1_const_ref' first required here
return set1_const_ref(data + w2 * i, w2);
Solved this by just defining those missing copy constructors explicitly, e.g.:
+ set1_const_ref(const set1_const_ref &o) : data(o.data), words(o.words) { }
After this, I'm looking at clang and gcc handling -Wformat-nonliteral
differently. Clang warns about this but gcc does not:
common.c:691:20: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
vsyslog(LOG_ERR, fmt, va);
^~~
common.c:693:20: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
vfprintf(stderr, fmt, va);
^~~
And another time in stapbpf.cxx:
stapbpf.cxx:257:20: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
vfprintf(stderr, str, va);
Not quite sure how to best handle these. Adding a
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wformat-nonliteral"
// Code
#pragma GCC diagnostic pop
block works for clang as well and is also done in e.g. stapbpf/bpfinterp.cxx
for other code. What do you think?
Other than that, the only problem left is the printsig() stuff from above.
--
You are receiving this mail because:
You are the assignee for the bug.
next prev parent reply other threads:[~2020-11-05 9:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 8:27 [Bug server/26839] New: " tbaeder at redhat dot com
2020-11-05 1:11 ` [Bug server/26839] " fche at redhat dot com
2020-11-05 1:23 ` fche at redhat dot com
2020-11-05 9:21 ` tbaeder at redhat dot com [this message]
2020-11-23 19:12 ` tstellar at redhat dot com
2020-11-24 7:52 ` tbaeder at redhat dot com
2021-01-18 12:06 ` tbaeder at redhat dot com
2021-01-18 15:10 ` tstellar at redhat dot com
2021-05-11 12:00 ` tbaeder at redhat dot com
2021-05-13 2:17 ` amerey at redhat dot com
2021-05-14 7:57 ` tbaeder at redhat dot com
2021-05-19 21:46 ` amerey at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-26839-6586-H0PpDUgedT@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).