Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote: > Could you test to compile LLVM with GCC old versions 4/5/6? Does it need > to backport your patch to GCC old version? GCC versions before 6.4 are not supported, so no backports will happen to 4.x or 5 releases and I doubt anybody's going to routinely test anything with them. If there's a bug in GCC 4.9.3 that you can't work around then you should upgrade to a supported release (or use a distribution that provides support for older releases).
gcov questions
Hello, I wanted to ask what model for
branch coverage does gcov use? Would it be branch, decision, condition
coverage or some modification like branch condition, branch condition
combination or modified condition decision coverage (MCDC)? Also for a simple
example as below: uint8 Func(uint8 a, uint8 b, uint8 c) { return ((a
> 5u) && (b < 15u) && (c == 0u)); } I get 6 branches.
The total number of possibilities is 8: F F F T F F F T F F F T T T F F
T T T F T T T T where
T is true and F is false. Which branches are taken into account? Why
does executing function with parameters Func(6u, 14u, 0u) results in 3
branches out of 6 being covered? I could understand that due to
short-circuit evaluation more branches could be covered when some
condition is false but not when all of them are true. What combination
of conditions is needed for full coverage in this case? Thank you for your
help. Best regards Darius
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
Hi Jonathan, Thanks for your response! So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5 to build old clang, then bootstrap latest LLVM with old clang. 在 2018年08月09日 17:16, Jonathan Wakely 写道: On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote: Could you test to compile LLVM with GCC old versions 4/5/6? Does it need to backport your patch to GCC old version? GCC versions before 6.4 are not supported, so no backports will happen to 4.x or 5 releases and I doubt anybody's going to routinely test anything with them. If there's a bug in GCC 4.9.3 that you can't work around then you should upgrade to a supported release (or use a distribution that provides support for older releases). -- Regards, Leslie Zhai
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
On Thu, 9 Aug 2018 at 12:04, Leslie Zhai wrote: > > Hi Jonathan, > > Thanks for your response! > > So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5 > to build old clang, then bootstrap latest LLVM with old clang. It would be much easier to just use -fno-strict-aliasing with the older GCC.
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
Author of the problematic code here. Thanks everyone, and sorry to have caused difficulty! Obviously if there really is something illegal here we should fix it in LLVM, but it looks like this warning is a false positive (anyone disagree?) Still if there's a simple source-level workaround, or we can suppress the warning with a #pragma, I'd be happy to do that. GCC 4.9.3 is a supported compiler for LLVM and the more configurations we build cleanly in, the better. If this is a useful direction, could someone with an affected environment send me a small patch? I don't have the right setup to verify myself. Cheers, Sam
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
Hi Sam,
Thanks for your response!
Please review it, thanks a lot!
A patch by Loongson!
diff --git a/include/llvm/Support/JSON.h b/include/llvm/Support/JSON.h
index da3c5ea..fd60b40 100644
--- a/include/llvm/Support/JSON.h
+++ b/include/llvm/Support/JSON.h
@@ -452,7 +452,10 @@ private:
new (reinterpret_cast(Union.buffer)) T(std::forward(V)...);
}
template T &as() const {
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstrict-aliasing"
return *reinterpret_cast(Union.buffer);
+#pragma GCC diagnostic pop
}
template
在 2018年08月09日 19:25, Sam McCall 写道:
Author of the problematic code here. Thanks everyone, and sorry to
have caused difficulty!
Obviously if there really is something illegal here we should fix it
in LLVM, but it looks like this warning is a false positive (anyone
disagree?)
False positive!
Still if there's a simple source-level workaround, or we can suppress
the warning with a #pragma, I'd be happy to do that. GCC 4.9.3 is a
supported compiler for LLVM and the more configurations we build
cleanly in, the better.
If this is a useful direction, could someone with an affected
environment send me a small patch? I don't have the right setup to
verify myself.
I test it for mips64el built with gcc-4-branch:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mips64el-redhat-linux/4.9.3/lto-wrapper
Target: mips64el-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-arch=loongson3a
--enable-languages=c,c++,objc,obj-c++,fortran,go,lto --enable-plugin
--disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.3/obj-mips64el-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.3/obj-mips64el-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-long-double-128
--build=mips64el-redhat-linux
Thread model: posix
gcc version 4.9.3 20150626 (Red Hat 4.9.3-8) (GCC)
Cheers, Sam
--
Regards,
Leslie Zhai
Proposal to extend -Wcoverage-mismatch diagnostic cases
Wcoverage-mismatch is meant to "Warn in case profiles in -fprofile-use do not match" Currently, gcc compiler warns about the following two cases of source code changes which alert the programmer to re-generate the profiles : 1. Control flow mismatch If functions' control flow has been altered after profile generation, the profile count data will not be able to match the cfg_checksum. Hence the warning, "warning: the control flow of function 'XXX' does not match its profile data (counter 'YYY') [-Werror=coverage-mismatch]" 2. Function is physically moved to a different location If existing functions are physically swapped in the source file, gcc alerts the user about potentially stale profiles for all the affected functions. Hence the warning, "warning : source locations for function 'XXX' have changed, the profile data may be out of date [-Werror=coverage-mismatch]" So, if new function foo() is added in the source file before existing functions, gcc alerts the user about potentially stale profiles of the already seen functions. Note however, there is no warning about the new function foo(). Hence, my proposal #3 below which will cover foo() in this scenario. Proposing to add the following cases which are not currently covered : 3. If a new function foo() is added to the file. Proposal to add a warning along the lines of - "warning : profile for function ‘XXX’ not found in profile data [-Wcoverage-mismatch]" The corner case of foo() being added to the end of the file is exclusively covered by #3. 4. A new source file is added to the project after profile generation phase. Proposal to add a warning per function along the lines of - "warning : profile count data file not found, regenerating profiles may help [-Wcoverage-mismatch]" For both #3 and #4, gcc currently does not warn. Although, one can infer that the count profile data for a specific function / file are missing from the dump files, adding warnings #3 and #4 makes the coverage-mismatch set of warnings more complete for a better end user experience.
Re: gcov questions
On 08/09/2018 02:38 AM, daro...@o2.pl wrote: Hello, I wanted to ask what model for branch coverage does gcov use? There is a comment at the start of gcc/profile.c that gives some details on how it works. It is computing execution counts for edges in the control flow graph. As for which edges get instrumented, basically, you construct a control flow graph, create a minimal spanning tree to cover the graph, and then you only need to instrument the edges not on the spanning tree, plus the function entry point. You can compute the rest of the edge counts from that. Then there are some tricks to improve efficiency by putting frequently executed edges on the minimal spanning tree, so that infrequently edges get instrumented. Gcov was originally written in 1990, based on an idea that came from Knuth's Art of Computer Programming. Ball & Larus wrote a nice paper in 1994 that does a good job of covering the methods used, though they may not have been aware of gcov at the time as it hadn't been accepted into GCC yet. This is "Optimally Profiling and Tracing Programs" TOPLAS July 1994. I don't know if there are free copies of that available. There may be better references available now, as these techniques are pretty widely known nowadays Jim
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
Thanks all for pitching in to help! On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall wrote: > > Obviously if there really is something illegal here we should fix it in > LLVM, but it looks like this warning is a false positive (anyone disagree?) The little I've read about strict aliasing rules leaves me firmly incompetent to judge what's valid and not :) But since both Clang and GCC 6+ are happy with this, it seems plausible that this would be a false positive. > Still if there's a simple source-level workaround, or we can suppress the > warning with a #pragma, I'd be happy to do that. GCC 4.9.3 is a supported > compiler for LLVM and the more configurations we build cleanly in, the > better. I *think* Leslie's warning-disable patch should work even with MSVC (it should ignore unknown #pragmas, right?). I can't think of a straight-up code change that would fix this. Cheers, - Kim
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
On Thu, 9 Aug 2018 at 22:59, Kim Gräsman wrote: > > Thanks all for pitching in to help! > > On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall wrote: > > > > Obviously if there really is something illegal here we should fix it in > > LLVM, but it looks like this warning is a false positive (anyone disagree?) > > The little I've read about strict aliasing rules leaves me firmly > incompetent to judge what's valid and not :) > > But since both Clang and GCC 6+ are happy with this, it seems > plausible that this would be a false positive. If GCC 4.9.3 thinks there's an aliasing violation it might misoptimise. It doesn't matter if it's right or not, it matters if it treats the code as undefined or not. And apparently GCC does think there's a violation, because it warns. Unless you're sure that not only is the code OK, but GCC is just being noisy and doesn't misoptimise, then I think using -fno-strict-aliasing is safer than just suppressing the warning. > > Still if there's a simple source-level workaround, or we can suppress the > > warning with a #pragma, I'd be happy to do that. GCC 4.9.3 is a supported > > compiler for LLVM and the more configurations we build cleanly in, the > > better. > > I *think* Leslie's warning-disable patch should work even with MSVC > (it should ignore unknown #pragmas, right?). I can't think of a > straight-up code change that would fix this. > > Cheers, > - Kim
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely wrote: > > If GCC 4.9.3 thinks there's an aliasing violation it might > misoptimise. It doesn't matter if it's right or not, it matters if it > treats the code as undefined or not. > > And apparently GCC does think there's a violation, because it warns. > > Unless you're sure that not only is the code OK, but GCC is just being > noisy and doesn't misoptimise, then I think using -fno-strict-aliasing > is safer than just suppressing the warning. Good point, I can see how that would play out nicer. So this would probably need to be addressed in the LLVM build system, I'll try and work up a patch tomorrow. Thanks, - Kim
gcc-7-20180809 is now available
Snapshot gcc-7-20180809 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180809/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 263455 You'll find: gcc-7-20180809.tar.xzComplete GCC SHA256=d34a5ba60cd13712988ff50ffba9d2b16d7f7c7daa9f2cf87a5b3752b0d77e92 SHA1=2fd19f352b4c1db238fd522e92926a802adaed78 Diffs from 7-20180802 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
在 2018-08-10 06:20, Kim Gräsman 写道: On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely wrote: If GCC 4.9.3 thinks there's an aliasing violation it might misoptimise. It doesn't matter if it's right or not, it matters if it treats the code as undefined or not. And apparently GCC does think there's a violation, because it warns. Unless you're sure that not only is the code OK, but GCC is just being noisy and doesn't misoptimise, then I think using -fno-strict-aliasing is safer than just suppressing the warning. Good point, I can see how that would play out nicer. So this would probably need to be addressed in the LLVM build system, I'll try and work up a patch tomorrow. When I used to do such type punning in C, I got similar warnings. Then I looked for some solutions... I can't recall the principle now and I fail to find it in the C or C++ standard. Despite that, the solution is simple: Only an lvalue of a pointer to (possibly CV-qualified) `void` or a pointer to a character type (in C) / any of `char`, `unsigned char` or `std::byte` (in C++) can alias objects. That is to say, in order to eliminate the aliasing problem an intermediate lvalue pointer is required. Hence, altering ``` return *reinterpret_cast(Union.buffer); ``` to ``` auto p = static_cast(Union.buffer); return *static_cast(p); ``` will probably resolve this problem. Thanks, - Kim -- Best regards, LH_Mouse
